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1 . 0  INTRODUCTION 


The  Specification  Language,  AXES,  is  a  formal  notation  for  writ¬ 
ing  functional  definitions  of  systems.  Although  it  is  not  a  pro¬ 
gramming  language,  AXES  is  a  complete  and  well-defined  language 
capable  of  being  analyzed  by  a  computer. 

Higher  Order  Software  (HOS)  (HAM7 6b)  is  a  formal  system  theory 
that  forms  the  foundations  of  the  Specification  Language,  AXES. 
HOS  is  a  unified  systems-engineering  methodology  that  encompasses 
S  all  phases  and  all  disciplines  of  computer-based  systems  develop¬ 

ment.  With  the  methodology  of  HOS,  we  apply  the  same  axioms 
(Appendix  I)  and  therefore  the  same  decomposition  techniques 
throughout  an  integrated  system  development  (HAM76c) .  AXES  is 
I  the  tool  for  defining  and  describing  functions  and  interfaces  of 

a  system  throughout  all  phases  of  a  system  development. 

The  purpose  of  AXES  is  to  be  able  to  express  a  specification  in 
I  a  form  which  is  equivalent  to  an  HOS  control  map  (HAM76a) .  Thus, 

systems  described  in  AXES  are  based  on  the  use  of  three  primi¬ 
tive  control  structures,  which  were  derived  from  the  HOS  axioms 
(Appendix  II).  Kith  the  syntax  of  AXES,  we  are  able  to  describe 
•  a  system  using  the  primitive  control  structures,  intrinsic  dr.ta 

types  and  universal  primitive  operations  of  AXES,  or  we  have  the 
option  of  defining  new  data  types  or  new  control  structures  which 

can  also  be  used  to  describe  a  system. 

I 

A  computer-based  AXES  analyzer  can  be  developed  in  order  to  check 
the  consistency  and  completeness  of  functions  described  within 

AXES  statements. 

t 


2.0  SEMANTIC  PRELIMINARIES  AND  A  NOT ATI ON AL  CONVENTION 


Throughout  our  description  of  AXES' ,  we  will  be  using  a  notation 
that  is  conventional  in  semantics,  but  that  may  not  be  familiar 
to  most  readers.  One  of  the  most  fundamental  insights  of  seman¬ 
tics  is  the  fact  that  we  can  calk  about  an  object  only  by  using 
a  name  of  the  object,  to  talk  about  the  man  in  Figure  2.1,  for 
example,  we  have  to  use  a  sentence  that  contains  the  man’s  name, 
not  the  man  himself. 


Figure  2.1 

The  sentence 

(1)  John  is  standing  beside  the  house 

is  a  true  description  of  the  situation  pictured  in  Figure  2.1, 
but  the  purported  sentence 

(2)  is  standing  beside  the  house 

is  not  a  sentence  at  all,  because  the  man  himself  appears  in  it, 
rather  than  his  name.  How  we  say  things  about  objects  is  always 
one  step  removed  from  the  objects  themselves. 

2 
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This  fact  is  so  basic  a  part  of  how  we  communicate  information 
that  we  generally  remain  entirely  unaware  of  it,  taking  it  entire¬ 
ly  for  granted  like  a  pulse  or  heartbeat.  When  it  is  brought 
tc  one's  attention,  it  may  even  seem  trival  or  unimportant. 

Serious  problems  can  arise,  however,  when  we  begin  talking  aboot 
a  language,  such  as  AXES,  rather  than  simply  using  a  language 
tc  talk  about  objects.  Since  how  we  say  something  must  of  ne¬ 
cessity  be  one  step  removed,  linguistically,  from  what  we  are 
saying  about  it,  great  care  must  be  taken  to  distinguish  the 
names  in  the  language  we  are  talking  about  from  the  names  in  tlie 
language  we  are  using. 

When  we  are  talking  about  a  language,  we  are  treating  the  names 
of  that  language  as  objects.  We  can  only  talk  about  those  ob¬ 
jects  (names)  ,  as  with  any  ''hjects,  by  using  names  of  them,  l-t 
follows  that  we  need  a  nota^on  for  names  of  names,  if  we  intend 
to  talk  consistently  about  names.  The  notation  conventionally 
used  for  this  in  semantics  is  enclosure  within  quotation  marks. 

To  form  the  name  of  a  given  name  (or  written  symbol  of  any  kind) 
we  include  that  name  (or  symbol)  in  quotation  marks. 

We  can  clarify  this  notation  somewhat  by  examining  a  few  examples. 
Consider  the  man  in  Figure  2.2  and  the  four  purported  sentences 
in  (3)  and  (4)  : 


Figure  2.2 
3 
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(3)  (a)  Jimmy  sells  peanuts 

(b)  *  Jimmy  is  bisyllabic 

V 

(4)  (a)  *  "Jimmy"  sells  peanuts 

(b)  "Jimmy"  is  bisyllabic 

In  both  pairs  of  purported  sentences  (3)  and  (4),  those  which 
are  prefixed  with  asterisks  (*)  are  not  really  sentences  at  all, 
but  meaningless  strings  of  words,  while  those  without  asterisks 
are  normal  meaningful  sentences  which  also  happen  to  be  true. 

Sentence  (3a)  uses  the  man's  name  to  talk  about  the  man,  saying 
that  the  man  sells  peanuts.  Purported  sentence  (4a),  in  contrast, 
is  not  using  a  name  of  the  man,  but  a  name  of  thJ  man's  name, 
since  the  name  it  uses  as  its  subject  is  the  man's  name  in  quotes. 

Since  (4a)  uses  the  name  of  a  name,  it  is  talking  about  a  name, 
saying  that  that  name  sells  peanuts,  an  obvious  absurdity. 

Sentence  (4b),  however,  is  all  right,  because,  while  also  talking 
about  a  name,  what  it  says  about  that  name  makes  sense.  Names 
cannot  sell  peanuts,  but  they  can  be  bisyllabic.  Purported  sen¬ 
tence  (3b),  conversely,  is  an  absurdity,  like  (4a).  By  using 
the  name  of  a  man  it  talks  about  the  man  himself,,  saying  that 
he  is  bisyllabic,  which  makes  no  sense. 

Successive  embedding  ol  quotation  marks  can  be  used  if  we  want 
to  talk  about  names,  names  of  names,  names  of  names  of  names, 
etc.,  as  illustrated  in  Figure  2.3. 


Figure  2.3 

i 
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If  we  begin  at  the  right  and  move  leftward,  we  first  have  our 
object,  the  man,  and  we  then  get  his  name.  To  talk  about  the 
man,  we  must  use  his  name.  We  are  then  free  to  view  that  name 
as  an  object  and  we  get  its  name  by  moving  one  more  step  to  the 
left.  To  talk  about  the  name  we  must  use  its  name  (i.e.,  the 
thing  in  quotation  marks) .  If  necessary  we  can  then  treat  that 
name  as  an  object  and  talk  about  it  using  its  name,  obtained  by 
moving  still  one  more  step  to  the  left.  What  we  obtain  then  is 
the  name  of  the  name  of  the  name  of  the  man,  which  we  use  to 
talk  about  the  name  of  the  name  of  the  roan.  The  process  can  be 
continued  indefinitely,  in  principle,  but  it  is  unlikely  that  we 
would  ever  have  to  go  beyond  the  steps  shown  in  the  diagram,  in 
actual  practice. 

The  main  point  to  be  kept  in  mind  is  the  need  to  distinguish 
carefully  between  an  object  ana  its  name  and  to  make  sure  that 
we  use  the  name,  not  the  object  itself,  to  talk  abont  the  object. 

In  (3)  and  (4)  we  saw  how  confusing  the  object  with  its  name  can 
turn  a  seemingly  normal  sentence  into  an  absurd *,ty..  Sometimes, 
however,  it  can  produce  a  perfectly  meaningful  sentence  whose 
actual  meaning  differs  from  what  it  was  intended  to  mean.  Each 
of  the  sentences 

(5)  Jimmy  sounds  funny 

(6)  "Jimmy-  sounds  funny 

is  a  perfectly  meaningful  sentence,  but  their  meanings  are  very 
different.  Sentence  (5)  makes  sense  if  completed  with 

(7)  in  contrast  with  Northerners 

but  sentence  (6)  must  be  completed  with  something  like 

(8)  because  it's  really  just  a  nick-name 
to  make  sense. 

5 
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If  we  add  (7)  to  (6)  or  (8)  to  (5) ,  we  get  meaningless  nonsense 
like  (3b)  and  (4a) . 

The  reason  this  principle  is  important  for  us,  of  course,  is  that 
we  are  describing  a  language,  AXES,  and  we  must  be  careful  that: 
what  we  say  about  that  language  makes  sense.  We  will  be  talking 
about  the  names  and  other  symbols  of  AXES,  i.e. ,  we  will  be  treat¬ 
ing  them  as  objects,  so  we  must  be  careful  to  use  their  names 
in  doing  so.  The  quotation-mark  convention  enables  us  to  form 
the  names  of  the  AXES  names  and  thus  to  talk  about  the  AXES  names 
themselves  in  a  consistent  way. 

In  AXES  what  corresponds  to  names  are  variables  and  constant  sym¬ 
bols.  A  constant  symbol  is  the  name  of  a  particular  value  and 
corresponds  to  a  proper  name  like  "John."  A  variable  is  the  name 
of  more  than  one  possible  value  and  corresponds  to  a  common  nous 
like  Ma  man.”  Figure  2.4a  exhibits  a  number  of  constant  symbols 
and  Figure  2.4b  exhibits  some  variables. 


.  1  \'*'1 

w 

*'  * 

*  tT 

V. 

rA 

A*  T ’•* 

a0  "■>?* 

r*.  t.(27 

*  ,  * 

'V 

A  <2  q 

X  ^ 

(a) 

(b) 

Figure  2.4 

note  that  the  quotation  mark  convention  applies  as  much  to  common 
nouns  as  to  proper  names.,  so  the  sentences 

A  man  has  two  arms 
"A  man”  contains  two  words 

make  sense,  while  the  purported  sentences 

6  C 
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"A  man"  has  two  arms 
A  man  contains  two  words 

do  not. 

In  describing  AXES  we  will  use  variables  and  constants  themselves 
to  make  statements  about  the  values  they  name,  and  we  will  use 
the  names  (quoted  forms)  of  variables  and  constants  to  make  state¬ 
ments  about  the  variables  and  constants  themselves.  The  sen¬ 
tences 


x  ■  y+z 
w  -  3 

x  is  an  integer 
y  and  z  are  of  the  same  type , 

for  example,  make  statements  about  values  by  using  the  variables 
and  constant  symbols  that  name  those  values.  Sentences  like 

"x*  represents  the  same  value  as  "y+z" 

"w"  represents  a  value  of  type  integer 

"y"  and  "z"  represent  values  of  the  same  type 

"q"  is  a  variable  and  "3"  is  a  constant  symbol. 


in  contrast,,  make  statements  about  variables  and  constant  symbols 
by  using  the  quotation-marked  symbols  that  name  thorn.  In  de¬ 
scribing  AXES  we  will  try  to  adhere  scrupulously  to  this  conven¬ 
tion,  so  that  it  will  always  be  clear  whether  we  are  talking 
about  the  objects  (values,  functions,  mappings,  structures,  etc.) 


that  AXES  talks  about  or  whether  we  are  talking  about  the  vari¬ 
ables  and  other  symbols  that  make  up  AXES  itself.  (Appendix  VI) 
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3.0  OBJECTS  OF  SPECIFICATION 

An  AXES  system  is  a  control  hierarchy.  The  structure  of  any 
hierarchy  is  determined  by  the  objects  that  belong  to  the  hier¬ 
archy  and  the  relationship  that  exists  between  the  objects  of 
the  hierarchy.  For  AXES  systems,  the  objects  are  variables,  values, 
functions,  and  trees?  the  relationship  is  control. 

An  AXES  system  can  be  graphically  represented  as  a  tree  in  which 
each  node  identifies  a  member  of  a  given  control  hierarchy. 

An  AXES  tree  structure,  called  a  control  map,  is  a  relation  on 
a  set  of  mappings,  i.e,  a  set  of  tuples  whose  members  are  sets 
of  ordered  pairs.  An  invocation  tree,  illustrated  in  Figure  3.1, 
exhibits  the  names  of  the  sets  of  ordered  pairs  (i.e~,  Mappings) 
which  complete  the  functional  specification  for  System  A.  When 
our  intent  is  to  understand  or  describe  the  relation  on  the  set 
of  mappings,  the  corresponding  function  of  System  A  is  described 
as  a  decomposition  of  A  into  levels.  The  most  immediate  lower 
level  of  A  is  a  realization  of  A  and  only  A.  Functions  A^  and 
A2  are  on  the  first  lower  level  of  A,  and  functions  B^  and  B2 
are  on  the  second  lower  level  of  A  with  respect  to  h^. 

A  controls  the  use  of  A^  and  a2?  A2  controls  the  use  of  B^  and 
S2 .  The  properties  of  control  are  determined  by  the  axioms  of 
HOS.  When  we  refer  to  a  controlling  A^  and  Aj,  A  i*  referred 
to  as  a  controller  or  as  a  module.  When  we  refesr  to  A^  with 
respect  to  A,  A^  is  referred  to  as  a  function. 


A 


Figure  3.1:  System  A  Invocation  Tree 
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A  control  map  includes  a  description  of  each  node  in  terms  of 
the  input/ output  representation  of  each  function  as  well  as  the 
name  associated  with  each  node  of  the  hierarchy.  A  control  map 
is  constructed  using  abstract  control  structures  (see  Section  8.0). 
A  control  map  of  System  A  is  shown  in  Figure  3.2. 


y 


Figure  3.2:  A  Control  Map  of  System  A 

A  representation  of  the  input  value  or  output  value  of  a  func¬ 
tion  is  called  an  input  or  output  variable,  respectively.  In 
(3-1),  "x"  is  an  input  variable  of  A;  "y"  is  an  output  variable 
Of  A. 

y  =  a  (x)  (3-1) 

Suppose  "x"  represents  any  one  of  the  integers  5,  8,  or  2.  We 
refer  to  these  integers  as  values  of  "x".  Likewise,  if  "y"  re¬ 
presents  any  one  of  the  integers  6,  10,  or  2,  we  refer  to  these 
integers  as  values  of  ”y" . 

In  an  AXES  system,  a  function  refers  to  the  relationship  (i.e., 
a  mapping)  between  the  input  values  and  the  output  values  where 
these  values  are  represented  by  particular  variables  (c.f.  FUNC¬ 
TION  definition  Section  8.0).  This  relationship  is  restricted 
in  AXES  so  that  any  input  value  corresponds  to  one  and  only  one 
output  value. 

A  data  type  is  a  set  of  values  characterized  by  a  set  of  primi¬ 
tive  operations.  When  a  variable  is  of  a  data  type,  that  vari¬ 
able  represents  a  value  of  that  data  type.  A  variable  of  a  data 
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type  may  be  replaced  by  a  set  of  variables  whose  values  collec¬ 
tively  represent  the  same  value  as  the  variables  of  the  data  type. 
This  collective  set  of  variables  is  the  data  structure  of  the 
variable  of  the  data  type. 

Suppose  "y"  in  (1)  is  replaced  by  "y^1  and  "y2",  and  "x"  by  "x^1 
and  "x2".  The  data  structure  of  x  is  (x^,x2) ,  and  the  data 
structure  of  y  is  (y^*y2) •  The  data  structures  of  x  and  y  could 
be  used  by  a  function,  such  as  B,  to  accomplish  the  same  mapping 
as  System  A. 

(y^Yj)  *  B(xlfx2)  (3-2) 

If  x  is  of  data  type  2-tuple  integer,  then  (1,10)  is  a  value 
of  "x".  If  y  is  of  data  type  2-tuple  integer,  then  (1,10)  is 
also  a  value  of  "y."  "x"  and  "y"  represent  the  same  set  of  *■ 

values,  i.e.,  "x"  and  "y"  are  variables  that  represent  values 
of  the  same  data  type.  A  and  B  are  equivalent  functions. 

When  our  intent  is  to  use  a  system  as  the  input  variable  or  out¬ 
put  variable  of  another  system,  A  is  of  data  type  system  and 
the  names  of  the  functions  on  the  first  immediate  lower  level 
of  A  (i.e.,  Aj^  and  A2)  describe  the  data  structure  of  System  a. 
Similarly,  and  B2  are  the  data  structure  of  A2«  When  "A" 
is  considered  an  input  or  output  variable  of  another  system,  "a" 
represents  a  layer . 

There  are  many  tradeoffs  that  must  be  considered  in  developing 
the  layers  of  a  system.  These  involve  not  only  how  many  layers, 
but  whether  or  not  these  layers  are  created  statically  (develop¬ 
ment  layers)  or  dynamically  (execution  layers) . 

If,  for  example,  a  translator  (such  as  a  compiler)  converted  one 
description  of  a  specification  of  A  to  another  description  of  a 
specification  of  A,  System  A  would  exist  as  at  least  two  develop¬ 
ment  layers.  If,  however,  a  real-time  translator  (such  as  an 


HIGHER  ORDER  SOFTWARE.  INC  •  M3  MASSACHUSETTS  AVENUE  -  CAMBRIDGE.  MASSACHUSETTS  02139  •  (617)  661-3900 


operating  system)  converted  a  System  A  layer  to  an  executable 
mode  in  real  time,  we  would  call  that  new  layer  of  A  an  execu¬ 
tion  layer. 


In  defining  a  system  it  may  be  necessary  to  describe  the  systei 
both  as  a  function  and  as  a  layer.  The  syntax  of  AXES  provides 
the  means  to  differentiate  between  these  two  concepts. 

The  intent  of  an  AXES  specification  is  to  describe  the  functional, 
data,  and  performance  aspects  of  a  system  independently  of  a 
particular  resource  allocation  (i.e.,  implementation).  The 
functional  description  provides  the  specification  of  the  decom¬ 
position  of  a  system;  the  data  description  provides  the  specifi¬ 
cation  for  the  data  types  and  structures  to  be  used  in  the  func¬ 
tional  specification;  the  performance  description  asserts  the 
limitations  or  constraints  associated  with  the  use  of  functional 
or  data  descriptions.  With  AXES  we  are  able  to  define  systems 
in  which  resource  allocation  requirements  (e.g.,  time  and  memory) 
can  be  specified,  thus  allowing  for  resource  allocation  alterna¬ 
tives.  Each  of  these  aspects  of  a  system  can  be  documented  in 
a  standard  way  with  AXES. 
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4.0  SPECIFICATION  VS.  IMPLEMENTATION  LANGUAGE 

Using  AXES,  a  system  designer  describes  a  system  as  a  set  of 
functions  and  data  that  look  very  much  like  the  procedures  and 
data  of  a  programming  language.  However,  the  functions  and  data 
of  AXES  differ  in  fundamental  ways  from  the  procedures  and  data 
of  programming  languages. 

In  programming  languages,  a  variable  "x"  is  a  name  that  desig¬ 
nates  a  unit  of  storage  where  values  may  be  placed.  That  is  a 
statement  of  the  form  "x  ■  y+z"  means,  "add  the  current  values 
of  *y ’  and  '  z1  and  store  the  result  in  ’x’".  In  AXES,  the  same 
statement  means  "'x*  represents  the  same  value  as  is  represented 
by  'y+z'".  In  AXES,  a  variable  is  the  name  of  a  particular  un¬ 
specified  value.  A  constant  symbol,  such  as  "2",  for  example, 
is,  in  contrast,  the  name  of  a  particular  specified  value.  The 
meaning  of  "x»y+z;"  in  AXES  differs  from  its  meaning  in  programm¬ 
ing  languages  also  as  a  result  of  a  difference  in  meaning  of  . 
In  a  programming  language,  is  a  directional  symbol  meaning 
"is  to  be  replaced  with."  The  statement  "x+y*z"  means,  in  effect, 
"replace  whatever  value  is  stored  in  'x'  with  the  result  of  adding 
whatever  value  is  stored  in  'y'  to  whatever  value  is  stored  in 
■z’ ."  In  AXES,  however,  is  a  non-directional  symbol  meaning 
"is  the  same  as."  The  statement  "x*y+z"  means  "the  value  of  'x' 
is  the  same  as  the  sum  of  the  value  of  'y'  and  the  value  of  •z*," 
or  equivalently,  "’x*  represents  the  same  value  as  ’y+z*  repre¬ 
sents."  The  interpretation  of  "■"  in  AXES  is  thus  identical  to 
the  interpretation  of  "■"  in  mathematics.  AXES  statements  are 
statements  of  fact;  they  are  not  commands  to  be  performed. 


Programming  languages  make  use  of  the  notion  of  an  order  of  evalu¬ 
ation  or  a  flow  of  execution.  There  is  no  such  notion  in  AXES. 

In  AXES  we  use  variables  to  specify  equality  relationships  among 
values.  AXES  serves  to  define  the  variables  that  represent 
values  in  terms  of  other  defined  variables  that  represent  values. 
In  AXES,  the  following  statements  simply  define  the  variables 
"x",  "w",  and  "z"  by  using  them  in  statements  of  equality. 
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x  *  a+b; 
w  =  5; 

2  ■  f (k) ; 


(4-1) 

(4-2) 

(4-3) 


Each  of  these  variables  represent  one  of  a  set.  of  values.  If 
statements  (4-1) , (4-2) ,  (4-3)  were  part  of  an  AXES  system  speci¬ 
fication,  (4-1)  could  appear  after  (4-3)  or  (4-2),  because  AXES 
statements  can  appear  in  any  order. 

In  AXES,  the  following  statement  defines  the  variable  "x*  by 
using  the  constant  symbol  "True". 

x  «  AND (True, True)  (4-4) 

In  AXES,  the  following  statement  defines  a  relationship  among 
systems . 

Sum(Prod (x,y) ,x)  *  Opp(x,Dif f (x,y)  (4-5) 

In  this  statement,  *'xM  always  represents  the  same  value,  and 
"yM  always  represents  the  same  value. 

In  AXES,  a  variable  is  specified  to  be  referenced  only  once  fox 
a  given  change  of  state  at  a  given  level  of  a  control  hierarchy. 

(This  is  called  single  reference.)  A  variable  is  specified  to 
be  assigned  only  once  for  a  given  change  of  state  at  a  given 
level  of  a  control  hierarchy.  (This  is  called  single  assign¬ 
ment)  .  Thus,  the  concept  of  sharing  locations,  is  not  assumed; 
yet,  this  concept  may  still  be  introduced  into  an  implementation 
model. 

Functions  are  defined  in  such  a  way  that  the  ordering  between 
functions  in  a  given  system  can  be  determined.  The  procedure* 
in  an  implementation  model  can  thus  exist  within  an  unlimited 
multiprocessor  system,  a  multiprogramming  system  or  a  sequential 
programming  system. 

13 
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Each  function  is  explicitly  shown  as  unique  in  AXES.  Yet,  the 
concept  of  sharing  instructions  may  still  be  introduced  into  an 
implementation  model. 

Each  AXES  function  is  specified  to  be  initiated  upon  receipt  of 
its  first  input  value.  An  AXES  function  is  ready  for  complete 
execution  upon  receipt  of  all  of  its  input  values  and  is  completed 
upon  receipt  of  all  its  output  values.  In  an  AXES  system,  the 
specification  of  a  value  is  synonomous  with  the  specification  of 
an  event.  Thus,  interrupts  or  searches  for  mvmnts  are  not  assumed; 
yet,  they  may  still  be  introduced  into  an  implementation  model. 
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5.0  NOMENCLATURE 


In  the  description  of  AXES  the  following  nomenclature  will  be 
used. 


means  "is". 


" {  }"  means  choose  one  of  the  rows  contained  witthin. 


"[  ]"  means  the  enclosed  is  optional. 


"..."  means  repeat  with  different  values  as  often  as 
necessary. 

In  the  syntax  of  AXES,  the  following  nomenclature  wiU.  be  used. 


Upper  case  names  will  designate  lexical  items  ot  AXES  (key¬ 
words)  . 


"set  of  variables"  means  a  list  of  variables  possibly  en¬ 
closed  in  parentheses. 

Constants  and  abstract  control  structure  names  begin  with 
an  upper  case  character  followed  by  zero  or  more  Jower  case 
characters. 


A  variable  is  indicated  by  all  lower  case  characters . 


A  valne  of  a  particular  data  type  can  be  indicated  by  the 
name  of  the  data  type  in  lower  case  characters,  jpossibly 
subscripted. 
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6 . 0  COMMENTS 


Comments  can  be  inserted  between  statements.  A  comment  is  de¬ 
limited  at  the  start  by  the  character  pair  /* ,  and  at  the  end  by 
the  character  pair  */.  Any  character  may  appear  in  the  comment 
(except  for  *  followed  by  /) . 


7.0  MULTI -LINE  FORMAT 

A  variable  in  AXES  can  be  a  subscripted  symbol,  a  superscripted 
symbol,  or  an  unsubscripted  or  un superscripted  symbol. 

AXES  allows  a  multi-line  format  (LIC74)  (LAN52)  corresponding: 
to  natural  mathematical  notation.  For  example,  the  following- 
statements  are  acceptable  in  AXES. 


Subscripts 


1yp(t)  -  F(x,t> 

2  2n 

a  *  d  +  c  +  d 

e 


The  subscripting  of  a  variable  in  AXES  always  signifies  a  map¬ 
ping  between  the  value  of  the  subscript  variable  and  the  value 
of  the  variable  that  is  subscripted.  Thus  "Ai"  shows  a  relation¬ 
ship  between  i  and  A.  If  that  relationship  is  function  F,  such 
that 

A.  -  F(i) 

"i"  could  represent  an  index  for  memory  slot  "A^“. 
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If  "x  "  related  x  and  t  by  function  G,  i.e., 


xt  =  G(t) 


"t"  could  represent  an  index  for  time  slot  "xt".  The  subscript 
mechanism  is  helpful  in  functionally  representing  the  specifi¬ 
cations  of  resource  allocation  of  storage  and  time  with  respect 
to  a  particular  system. 


Superscripts 


A  variable  with  a  left  superscript  represents  a  member  of  a 
member  of  a  partition  of  &  set  of  values.  For  example,  if  x 
is  an  integer,  the  members  of  the  sets  that  make  up  a  parti¬ 
tion  of  the  set  of  which  x  is  a  member  might  be  represented  by 
"  x"  and  "  x"  where  "  x"  represents  values  greater  than  10, 
and  "2x"  represents  values  less  than  or  equal  to  10. 

A  variable  with  a  right  superscript  is  an  alternate  notation 
associated  with  particular  operations  on  intrinsic  data  types 
of  AXES  (for  example,  "x2"  means  "multiply  the  value  of  'x' 
by  the  value  of  'x'").  In  other  words,  right  superscripts  rep' 
resent  mathematical  exponents. 


i 

f 
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8.0  ABSTRACT  CONTROL  STRUCTURES 


An  abstract  control  structure  (ACS)  is  a  control  hiierarchy. 

An  ACS  can  be  generalized  to  be  used  in  many  particular  systems, 
or  it  can  be  "tailored"  to  the  needs  of  a  specific  application. 

An  ACS  can  define  one  or  more  of  its  variables  or  nappings  re¬ 
cursively.  In  such  circumstances,  the  recursive  invocation  of 
the  mapping  defines  a  new  instance  of  variables  associated  with 
the  ACS. 

Abstract  control  structures  have  three  forms  in  ACS::  structures, 
operations,  and  functions.  - -  . 

A  structure  is  a  relation  on  the  se4  of  mappings,  iL.e.,  a 
set  of  tuples  whose  members  are  sets  of  ordered  paizrs.  We 
specify  a  structure  by 

"STRUCTURE:"  y  S  "("  x  "};" 
declaration. . . 
definition. . . 

"SYNTAX:"  user  defined  syntax";* 

"END"  S  ";" 

user  defined  syntax:  «  connector ^  y^  "■*  *("x^")"... 

connector  y„  "■"  $_  "("x  *)" 
n  Jn  n  n 

where  x,  y  are  variables  or  sets  of  variables  whose;  values  are 
in  the  same  types  as  the  members  of  the  ordered  passes  that  make 
up  the  mappings  in  the  tuples  of  S; 
and  r  is  a  structure  name; 

and  connector^  is  a  user-defined  name,  possibly  empnty; 

and  yi  *  S^x^)  aTi  unspecified  mapping  (see  Sectiion  10.0  for 

use  of  U3er-defined  syntax) . 

The  unspecified  mapping  names,  used  in  definition  sttatements  within 
a  structure,  are  nested  subscripted  names  with  respcect  to  the  root 
module  name.  For  example, 
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STRUCTURE:  y  -  F(x) ; 


y  =  F1(g)  AND  g  *  F2(x)  ; 

y  *  F.  (h)  AND  h  *  F,  (g) ; 
il  ^1 

A  structure  is  an  ACS  in  which  the  root  module’s  corresponding 
function  is  not  specified  and  in  which  at  least  two  other  members 
of  the  same  control  hierarchy  exist  as  unspecified  functions. 

The  STRUCTURE  definitions  for  the  three  primitive  control  struc¬ 
tures  are  defined  in  Section  12,0.  The  user-defined  syntax  can 
be  used  in  the  construction  of  new  structures,  operations,  or 
functions. 

By  an  operation,  we  mean  a  set  of  mappings  which  stand  In  a 
particular  relation.  An  operation  results,  mathematically,  from 
taking  particular  mappings  as  the  arguments  (nodes)  of  a  struc¬ 
ture.  In  AXES,  we  define  a  particular  operation  by  means  of  the 
following  syntax: 

-OPERATION:-  y  "*B  L  " ("  x  " 
declaration. . . 
definition. . . 

-END"  L 

where  x,  y  are  variables  or  sets  of  variables  whose  values  are 
in  the  same  types  as  the  members  of  the  ordered  pairs  which  are 
the  mappings, 

and  L  is  an  operation  name. 

An  operation  is  an  ACS  in  which  the  root  module  has  a  corres¬ 
ponding  mapping  and  in  which  all  the  members  of  the  same  control 
hierarchy  exist  as  at  least  a  mapping  and  at  most  a  function, but 
not  all  are  functions. 
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A  universal  primitive  operation  is  an  operation  whose  arguments 
can  be  values  of  any  variable  or  set  of  variables.  In  AXES, 
universal  primitive  operations  are  used  with  ACS  definitions 
to  construct  new  ACS  definitions.  The  universal  primitive  opera¬ 
tions  in  AXES  are: 

The  set  of  CLONE  operations 

,  (x, . . .x)  -  CLONE , (x) 

1  i  1 

here,"x"  has  the  value  of  "x";  "x"  has  the  value  of  "x"... 

1  2 

"x"  has  the  value  of  "x" 
i 

The  set  of  IDENTIFY  operations 

(x  ,...)  -  IDENTIFY®  (x. , < • . x) 

^n^  n^ >  • • •  i  m 

where  n^,...  is  a  list  of  integer  values  in  the  range  1  to 

m  and  n^  t  n^  ; 

here,  "x  "  has  the  value  of  "x.",... 

I1  1 

"x  H  has  the  value  of  *x  " 

^n  n 

For  example, 

(g,h, i}  -  IDENTIFY^ ^ ^ 5  (a,b,c,d,e) 

means  "g"  has  the  value  of  "b" 

"h"  has  the  value  of  "d" 

"i"  has  the  value  of  "e" 

The  set  of  K  operations 
y  "  Kconstant^ 

which  maps  any  value  of  variable  *.  *‘r*to  a  constant  value. 
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For  example, 


y  -  KTrue(x) 

meariS  My"  has  the  value  True  for  any  value  of  variable  "x" . 

AXES  introduces  a  special  value  of  any  variable,  REJECT.  The 
operation 

y  “  KREJECT(x) 

is  used,  for  example,  to  construct  ACSs  for  error  detection  and 
recovery  mechanisms. 

By  a  function  we  mean  a  set  of  mappings  which  stand  in  a  par¬ 
ticular  relation  for  which  particular  variables  have  been  chosen 
to  represent  their  inputs  and  outputs.  Whereas  structures  and 
operations  can  be  described  as  purely  mathematical  constructs, 
a  function  is  a  hybrid,  consisting  of  a  mathematical  construct, 
i.e.,  an  operation  and  a  linguistic  construct,  i.e.,  an  assign¬ 
ment  of  particular  names  to  inputs,  and  outputs.  In  AXES,  we 
define  a  particular  function  by  means  of  the  following  syntax: 

"FUNCTION:"  y  F  " {"  x  ");" 
declaration. . . 
definition. . . 

"END"  F  ";" 

where  x,  y  are  particular  variables  or  particular  sets  of  vari¬ 
ables  whose  values  are  in  the  same  types  as  the  members  of  the 
ordered  pairs  which  are  the  mappings/ 
and  F  is  a  function  name. 

A  function  is  an  ACS  in  which  the  root  module  has  a  correspond¬ 
ing  mapping  and  particular  variables  and  in  which  all  nodes  with¬ 
in  the  module's  control  hierarchy  exist  as  mappings  with  particu¬ 
lar  variables.  Note  that  our  use  of  "function”  is  slightly 
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different  from  what  is  meant  by  "function"  in  mathematics.  For 
the  latter  notion  we  ute  the  term  "mapping"  throughout  this  re¬ 
port. 


i 
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9 . 0  DECLARATIONS 


AXES  has  very  simple  name  rules.  If  a  name  is  declared  outside 
of  any  function,  operation  or  structure  definition,  it  is  the 
name  of  an  operation,  function,  or  constant. 

A  declaration  statement  has  two  forms  in  AXES.  A  WHERE  state¬ 
ment  is  used  to  specify  a  variable  as  the  name  of  a  value  of  a 
data  type.  A  PARTITION  statement  is  used  to  specify  nonover— 
lapping  (i.e.,  mutually  exclusive)  exhaustive  subsets  of  a  set 

of  values. 

WHERE 

The  names  used  within  an  ACS  are  either  declared  within  an  ACS 
definition  by  a  WHERE  statement,  or  are  the  names  used  for  func¬ 
tions,  operations,  and  types. 


In  declaration^  x  is  a  variable,  y^...  is  a  set  of  variable®, 

T  is  a  constant  or  variable  data  type  name,  and  "S"  concatenated 
with  T  denotes  a  plural  type  name. 


declaration^  ■  "WHERE"!  x  "TS" 


I" AN")  ^CONSTANT}  T 

({"A"  1  jTi  .  .  .  1 

Jl"AN"J  lTi"OR". .  .TrJ 

"OF  SOME  TYPE" 


) 


Xl  ' 


'ARE"  I  ("CONSTANT"]  T"S" 
|Tj...T"S" 

Vs"  "OR"... VS) 

"OF  SOME  TYPES" 

"OF  THE  SAME  TYPE"1 


:»  .  * 
f 


x  "IS1 


1 


l 


"TO  J  "  /  "  N  HIM 

l  Yi  •  •••  I 


•SOME  TYPE’ 
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In  the  example 

WHERE  x  IS  A  RATIONAL; 

WHERE  y  IS  AN  INTEGER; 

X  e  RATIONAL, 
y  €  INTEGER. 

In  the  example 

WHERE  Zero  IS  A  CONSTANT  NATURAL; 

"Zero"  represents  a  particular  value  of  data  type  NATURAL. 

Which  particular  value  it  represents  is  determined  by  the  axioms 
or  assertions  the  example  statement  might  occur  with  (see  Section 
15.0) . 

In  the  example 

WHERE  x  IS  AN  ARRAY  INTEGER; 
x  is  an  integer  member  of  an  ARRAY  member. 

It  is  sometimes  useful  to  specify  an  operator  that  is  capable 
of  operating  on  data  of  more  than  one  type.  For  example,  an 
operation  that  sums  several  input  arguments  could  accept  both 
INTEGER  and  RATIONAL  arguments.  It  is  even  possible  to  write 
operations  that  will  accept  arguments  of  any  type.  For  example, 
an  operation  that  compared  two  input  arguments  for  equality  could 
accept  arguments  of  any  type.  For  example, 

WHERE  X  IS  A  NATURAL  OR  RATIONAL; 

declares  "x"  to  be  a  variable  capable  of  being  defined  to  have 
either  NATURAL  values  or  RATIONAL  values. 

In  the  example, 

WHERE  X  IS  OF  SOME  TYPE; 

"x"  is  declared  to  be  a  variable  whose  values  are  of  an  unspecified 
data  type. 
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In  the  example 


WHERE  x,  y  ARE  INTEGERS; 

x  e  INTEGER,  y  e  INTEGER,  i.e.,  both  "x"  and  "y"  represent  in- 
gers. 

In  the  example, 

WHERE  X,  y  ARE  SAME  TYPE; 

"x"  and  "y"  are  declared  to  be  variables  capable  oaf  being  defined 
to  have  values  of  the  same  type,  where  the  type  iss  unspecified. 

In  the  example, 

WHERE  x  IS  (x1,x2)  ; 

WHERE  y  IS  A  RATIONAL; 

x  -  (x^,x2)  ,  i.e.,  "(x^,x2)"  is  the  data  structure*  of  "x". 

y  =  RATIONAL,  i.e.,  "y"  is  a  variable  whose  value  .is  the  set  of 
RATIONAL  values. 

PARTITION 

In  declaration2 ,  x  is  a  variable  or  a  set  of  variaibles  enclosed 
in  parentheses,  ^y  is  variable  or  set  of  variables;  whose  values 
are  members  of  the  members  of  a  partition  of  the  sset  of  values 
of  the  variables  that  x  represents. 


declaration^  *  "PARTITION  OF"  x  "IS" 


ANY  PARTITION 

ly  "|"  tVj  V...V 


tv. 
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m 


and 


If  "("expj")"  | 

true  val  exp:  'F  "("exp. .  .'iyl 

^  exp  F  exp 

tv  .  =  true  val  exp  1 

*  "("true  val  expj  "/'...true  val  eacp^")  "j 

true  val  exp^  evaluates  to  the  boolean  value  True,  and  exp  is 
in  terras  of  x  and  values  of  x. 

The  example 

PARTITION  OF  a  IS  Xa|a  >  10, 

2a | a  <  10, 

3a|a  =  10; 

12  3 

declares  the  set  a,  a,  a  to  be  a  partition  of  the  set  of  which 
a  is  a  member. 

The  example 

PARTITION  OF  (a,b)  IS  1(a,b)|a>b, 

2 (a,b) |a<b; 

12  .  . 

declares  the  set  (a,b) ,  (a,b)  to  be  a  partition  of  the  set  of 

which  (a,b)  is  a  member. 

In  the  use  of  a  member  of  a  partition,  the  left  superscript  can 

1 

be  distributed  to  each  member  of  a  set  of  variables,  e.g.,  "  (a,b)H 
can  be  written  "3a",  "3b". 
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10.0  DEFINITIONS 


A  definition  statement  defines  a  particular  control  level  by 
means  of  a  mapping  reference,  a  primitive  definition  statement, 
a  user-defined  definition  statement,  or  a  mapping  assertion 
statement. 


In  a  definition,  y,x  are  variables  or  sets  of  variables,  and 
F  is  a  structure,  operation,  or  function. 

y  "  =  "  p  ••  ("  x  ")  « 

primitive  definition 

t  t 

user-defined  definition 
mapping  assertion 

(^efinition^  "AND"... 
definition^ ; " 

An  example  of  a  primitive  definition  for  the  function  y  =  f(h)  is 
y  =  A  (b)  AND  b  *  C  (d)  AND  d  «  E(h); 


definition^:  = 


Primitive  definition:  « 


user-defined  definition:  = 


connector^  definition^. . . 

connector  definition 
n  n 


where  a  set  of  connectors  is  defined  in  a  particular  structure 
definition  (see  Section  8.0). 


An  example  of  a  user -defined  definition  is 
JOIN  y  «=  f^g) 

WITH  g  *  f2(a,b)  AND  (a,b>  =  f-jtx); 


Section  13  provides  more  examples  of  the  use  of  user-defined 
definitions.  Examples  of  connector  definitions  are  shown  in 
Section  12.0. 
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mapping  assertion:  =  "WHEREBY"  y  exp";" 

A  mapping  assertion  defines  a  mapping  in  terms  o±  operations 
that  have  been  previously  characterized  and  in  terms  of  bound 
variables. 

If  a  mapping  assertion  is  used  as  a  definition,  -the  corresponding 
function  has  the  set  of  variables  referenced  in  tfche  mapping  as¬ 
sertion  as  input  variables.  For  example, 

•> 

y  =  F^(a,b)  might  correspond  to  F^(a,b)  =  a  +  a/b  +  1. 

In  this  case,  we  can  write 

WHEREBY  y  =  a2  +  a/b  +  1 
to  define  the  mapping  F^. 

Examples  of  mapping  assertions  are: 

WHEREBY  z  =  g2  +  1; 

WHEREBY  (c,d)  «  (3.4)  ; 

WHEREBY  z  =  Sum (Prod (a ,b) ,a) ; 

WHEREBY  e  =  g(k(c)  }  ; 
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11 .0  EXPRESSIONS 

Expressions  in  AXES  are  similar  to  expressions  of  most  program¬ 
ming  languages. 


exp:  = 


value 

x 

F (exp) 
exp  F  exp 
(exp) 
exp , .. . 


where  F  is  an  operation  or  a  function  name  and 
x  is  a  variable. 


The  following  is  a  valid  expression: 

-a2  +  b/(c  +  f (x) )  +4 

When  operations  are  used  with  prefix  notation,  operator  hierarchy 
and  order  of  evaluation  are  inherently  determined. 

For  convenience,  AXES  permits  a  number  of  the  primitive  or  auxili¬ 
ary  operations  defined  on  intrinsic  data  types  (c.f.  Appendix  IV) 
to  be  written  in  terms  of  the  customary  prefix  or  infix  symbols. 
The  correspondences  between  these  operations  and  symbols  is  given 
in  the  following  table: 

Operation 

Or,  Per 
And,  Pand 

Not,  Pnot,  Iopp ,  Rop? 

Same,  Ident,  Equal,  ?Equal?, 

?Iequal?,  PRequal? 

?>?,  ?I>?,  ?R>? 

Sum,  Isum,  Rsum 

Idiff,  Rdiff 

Prod,  iprod,  Rprod 


Symbols 

I 

• 

t 

prefix  - 

m 

> 

+ 

* 
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Operation  (con't) 

Rdiv 

Cone 


Symbols  (con't) 


Given  these  symbolizations,  and  "<"  can  also  be  intro¬ 

duced  in  the  usual  way  as  abbreviations  for  combinations  of  these 
symbols.'  The  symbol  "+"  can  also  be  used  as  a  prefix  to  indicate 
the  identity  mapping,  and  the  symbol  "**"  can  be  used  to  indicate 
exponents.  All  symbols  in  this  table  are  infix  symbols,  except 
for  the  one  prefix  symbol  indicated. 

Operator  Precedence 

The  meaning  of  expressions  that  contain  multiple  operators  is 
determined  by  the  relative  priority  or  precedence  of  the  opera¬ 
tors  and  by  a  property  of  operators  called  associativity. 

The  expression 


a+b*c 


for  example,  means 
a+(b*c) 

because  has  higher  precedence  than  "+".  In  general,  operators 
of  higher  precedence  take  priority  over  operators  of  lower  pre¬ 
cedence.  The  precedence  of  AXES  operators  is  as  follows: 


Highest 


**  prefix  +  - 

*  / 

+  - 

»  <  >  <  =  > = 


Lowest 
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Operator  associativit' 


If  an  expression  contains  multiple  operators  of  equal  precedence, 
the  meaning  of  the  expression  is  determined  by  the  associativity 
of  the  operators.  All  prefix  operators  and  the"**"  infix  operator 
are  right-associative,  and  all  other  operators  are  left-associa¬ 
tive  . 

Left-associative  operators  give  priority  to  other  operators  of 
equal  precedence  to  their  left,  while  right-associative  operators 
give  priority  to  operators  of  equal  precedence  to  their  right. 

For  example, 

a+b+c-d 

means 

( (a+b) +c) -d 

while 

a**b**c 

means 

a**fb**c) 

As  in  most  programming  languages,  parentheses  can  be  used  to 
clarify  the  meaning  of  expressions  and  to  overrule  the  precedence 
and  associativity  of  operators. 
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12.0  PRIMITIVE  ABSTRACT  CONTROL  STRUCTURES  AS  STRUCTURES 


The  primitive  abstract  control  structures  of  HOS  can  be  defined 
as  structures.  The  structure  primitive  composition ,  for  example, 
is  the  relation  that  holds  among  three  mappings  Cn,  Cn^  Cn2 
if  Domain (Cn)  =  Domain (Cn2) ,  Range (Cn)  *  Range  (Cn^,  and  Do-  ' 
mainfCn^)  =  Range (Cn2) ,  and  if,  for  all  xf  y  such  that  y  =  Cn(x), 
there  is  a  g  e  DomainfC^)  such  that  y  =  C^  (g)  and  g  =  Cn2(x)  . 

In  AXES,  we  define  the  particular  primitive  composition  struc¬ 
ture  by  means  of  the  following  syntax. 

STRUCTURE:  y  =  Cn(x) ; 

WHERE  x,  y,  g  ARE  OF  SOME  TYPES; 
y  =  Cn^ (g)  AND  g  =  Cn2(x); 

SYNTAX:  JOIN  y  «  Cn^ (g)  WITH  g  *  Cn2(x); 

END  Cn; 

The  structure  class  partition  is  the  relation  that  holds  between 
three  mappings,  Cp,  Cp^f  Cp2if  Domain (Cp)  *  Domain (Cp^)  X  Do¬ 
main  (Cp2)  ,  Rarge(Cp)  *  RangefC?^  X  Range (cp2)  ,  and,  if  for  all 
x,  y  such  that  y  ■  Cp(x),  there  is  a  (y1#y2)  *  y  and  a  (x1,x2)  *  x 
such  that  y1  *  Cp1(x1)  and  y2  »  Cp2(x2) . 

In  AXES,  we  define  the  particular  class  partition  structure 
by  means  of  the  following  syntax: 

STRUCTURE:  (y  ,  y  2)  =  Cp(x^,x2); 

WHERE  X1#  x2,  y1#  y2  ARE  OF  SOME  TYPES; 

Y1  m  Cp^x^  AND  y2  =  Cp2(x2); 

SYNTAX:  INCLUDE  y1  =  Cp^x^  ALSO  y2  -  Cp2<x2); 

END  Cp; 
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The  structure  set  partition  is  the  relation  that  holds  between 
three  mappings,  Sp,  Sp^,  Sp2  if  Domain (Sp)  =  Domain (Sp^)  u 
Domain{Sp2)  and  Domain (Sp^) n  Domain (Sp2)  =  0,  and  Range  (Sp)  * 
Range  (Sp, )  U  Range (Sp.)  and  if,  for  all  x,  y  such  that  y  * 

1  1  i  2 

Sp(x),  there  is  either  a  y  s  Sp(  x)  or  a  y  =  Sp(  x), 

In  AXES  we  define  the  particular  set  partition  structure  by  means 
of  the  following  syntax: 

STRUCTURE:  y  =  Sp(x)  ; 

WHERE  x,  y  ARE  OF  SOME  TYPES; 

\  "  Sp]_(1x)  AND  ly  =  Sp2  ( 2x)  ; 

PARTITION  OF  (x,y)  IS  ANY  PARTITION; 

SYNTAX:  EITHER  *y  =  Sp-^x)  OTHERWISE  2y  =  Sp2(2x); 

END  Sp; 
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13.0  THE  USE  OF  STRUCTURES,  OPERATIONS  AND  FUNCTIONS 

In  the  following  examples,  the  data  types  referenced  are 
intrinsic  data  types  of  AXES  (Appendix  IV)  unless  otherwise 
indicated. 

An  example  of  an  operation  using  the  Cn  structure  is: 

OPERATION:  y  «  Transform  (a,b) 

WHERE  a,b  ARE  RATIONALS ; 

WHERE  y,g  ARE  INTEGERS; 

JOIN  y  =  A (g)  WITH  g  =  B(a,b); 

END  Transform; 

In  this  example,  the  structure  input  variable  has  been  replaced 
by  a  list  of  variables. 

A  function  can  include  the  use  of  structures  and  operations. 

For  example,  function  G  uses  the  Cn  structure  and  the  Trans¬ 
form  operation. 

FUNCTION:  C  «  G(d); 

WHERE  h  IS  A  RATIONAL; 

WHERE  C1,c2,h1,h2,d  ARE  INTEGERS; 

WHERE  C  «  (c^Cj) ; 

WHERE  h  -  (hlfh2) ; 

JOIN  c  =  R(h)  WITH  h  =  Trans form (d ) ; 

INCLUDE  c1  -  T(hx)  ALSO  c2  «  W(h2) ; 

END  G; 

An  example  of  a  function  using  the  Sp  structure  is: 

FUNCTION:  y  -  Decide  (x) ; 

WHERE  x,y  ARE  INTEGERS; 

EITHER  y  «  A(1x)  OTHERWISE  y  *  B(2x); 

PARTITION  OF  X  is  1x  |  x<  10 , 2x  |  X_>  10 ; 

END  Decide; 
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In  function  S,  function  Calculate  begins  at  time  b  «and 
completes  at  time  a.  Here  the  execution  time  span  cof 
Calculate  is  defined  by  function  Clock.  We  assume  ihere, 
an  extrinsic  data  type,  Timeslot,  where  x  and  y  are.*  Time- 
slots  whose  values  are  integers  and  an  extrinsic  datta  type, 
TIME. 

FUNCTION:  (a,y  )  =  S(b,x.  )? 

a  b 

WHERE  y,x  ARE  TIMESLOT  INTEGERS; 

WHERE  a,b  are  TIMES; 

INCLUDE  a  =  Clock (b)  ALSO  y  =  Calculate (x.) ? 

a  b 

END  S; 

A  complete  system  specification  is  defined  as  a  structure  of 
functions  whose  lowest  level  functions  are  primitives 
operations  on  the  data  types  represented  by  the  variables 
of  those  lowest  level  functions.  An  example  of  a  ccamplete 
system  definition  is  system  F.  The  lowest  level  functions 
of  system  F^  (i.e.,  F^  and  F2>  are  described  in  termas  of 
primitive  operations  on  RATIONALS .  The  intent  of  system  F 
is  to  perform  two  independent  functions. 

FUNCTION:  (y1,y2)  »  Ffx^Xj); 

WHERE  y^,y2,x1,x2  ARE  RATIONALS; 

INCLUDE  yx  =  als0  y2  "  F2(x2)? 

END  F; 

FUNCTION:  y1  -  F^x^; 

WHERE  y1,x1,g  ARE  RATIONALS; 

JOIN  WHEREBY  yx  *  g+1  WITH  WHEREBY  g  -  x^KJy^; 

END  F^ ; 
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FUNCTION:  y2  =  F2 (x2> ; 

WHERE  Y2,x2  ARE  RATIONALS ? 

EITHER  WHEREBY  y,  =  a2,  OTHERWISE  WHEREBY  y  =  b3; 
PARTITION  OF  x2  is  a|x2<10,  b|x2>10; 

END  F2; 

The  control  map  for  System  F  is  shown  in  Figure  13.1. 
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14.0  FUNCTION  FAILURE 


Failure  of  a  function  means  that  none  of  its  outputs  are 
defined. 


If  a  function  fails,  the  failure  could  propagate  back  up  to 
the  function  that  referenced  it,  etc.,  all  the  way  Iback  to 
the  top  of  the  system,  causing  the  system  to  fail. 


To  permit  orderly  recovery  from  errors,  AXES  provides  a 
structure  in  which  provision  for  failure  can  bo  expressed . 


STRUCTURE:  w  =  FAIL(X,y); 

WHERE  X,y,w  ARE  OF  SOME  TYPES; 

JOIN  w  =  Fail. (w, ^y )  WITH  (w,y)  Fail,(x,y); 

11  11  1 

EITHER  (Lw, Ly )  =  Fail  (1(x,y))  OTHERWISE 
11  2 

WHEREBY  2W  =  REJECT,  2y  =  2y; 

1  1 

PARTITION  OF  ‘(x,y,W,y)  IS 

.1  1 

1  (X,y ,w,y)|(x  NOT=  REJECT,  w  NOT=  REJECT), 

11  1 

2  (X,  y,w,y  )|(x=REJECT,w» REJECT)  ; 

11  1 

JOIN  ( Lw , Xy )  =  Fail.  (1x,1y,1y)  WITH 
11  112  1  2  3 

(1y,1y)  ■  CLONE- (Xy)  AND  1X  ■  CLONE. (1x)r 
2  3  1  1 

INCLUDE  1w  =  Fail.  (^x^y)  ALSO  1y  =*  CLONE,  {^y)  ; 

1  1.  1  2  1  1  3 

i2 

INCLUDE  1w  =  Fail  (1w,1y)  ALSO  2w  =  IDENTIFY*  (( 2W,  2y)  ; 

X1  1  1  11 

PARTITION  OF  (W,y,w)  IS 
1  1 

1 (w,y , w)  jw  =  REJECT, 

11  1 


2 


(w,y,w)  jw  NOT=  REJECT; 
1  1 


;] 
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JOIN  Xw  =  Fail  ( 1y)  WITH  1y  =  IDENTIFY? (Xw, 1y) ; 

11  2  2  1.  1 

SYNTAX:  w  =  Failj^  (x,y)  FAILURE  w  =  Fail  (y)  ; 

h  1, 

12  1 

END  Fail; 

Using  the  Fail  structure,  a  function  definition  statement  such 
as 


z  =  F(x,y,a)  FAILURE  z  =  G(y,a); 

implies  if  F(x,y,a)  fails,  G(y,a)  will  be  used  to  define  the 
value  for  z.  If  G(y,a)  might  fail,  we  can  write: 

z  =  F(x,y,a)  FAILURE  z  =  G(y,a)  FAILURE  z  =  H(a); 

If  H(a)  might  fail,  the  failure  propagates  back  to  the  controller 
function  which  either  uses  a  Fail  structure  of  its  own  or 
further  propagates  the  error  back  up  the  system- 
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15.0  DATA  TYPES 


Abstract  Types 

The  meaning  of  a  type  of  value  is  determined  by  the  set  of  opera¬ 
tions  that  can  be  performed  on  the  values  of  that  type.  For  ex¬ 
ample,  what  it  means  to  be  an  integer  is  determined  by  the  set 
of  operations  that  can  be  performed  on  integers. 

Most  programming  languages  define  a  limited  set  of  data  types 
and  a  set  of  operations  on  those  data  types.  More  advanced  lan¬ 
guages  allow  the  programmer  to  define  new  data  types  in  terms 
of  existing  or  previously  defined  data  types.  Because  these  de¬ 
finitions  define  the  new  data  types  in  terms  of  base  types,  how¬ 
ever,  the  newly  defined  types  usually  exhibit  the  properties  of 
their  base  types.  For  example,  if  the  type  department_numbers 
is  defined  in  terms  of  the  type  INTEGER,  department_numbers  are 
likely  to  be  permitted  as  operands  of  arithmetic  operators. 

In  AXES,  new  data  types  can  be  defined  simply  in  terms  of  the 
operations  that  are  to  be  performed  on  the  data  (GUT75) (Appen¬ 
dixes  III  and  IV) .  To  specify  a  data  type  in  AXES,  we  use  the 
following  syntax: 


"DATA  TYPE:"  name 
"PRIMITIVE  OPERATIONS;" 

primitive  operations. . . 
"AXIOMS;" 

declaration. . . 
assertion  (about  a  type) . . . 
"END"  name";" 


where  F 

(1)  name  is  the  abstract  data  type  name.  I 

(2)  the  primitive  operations  are  not  defined  in  terms  of  other  I 

operations,  but  in  terras  of  each  other.  As  with  all  operations,  I 

the  name  of  each  primitive  operation  is  known  throughout  the  J 
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****** 


system  specification,  and  each  primitive  operation  can  be  refer¬ 
enced  from  within  any  ACS  and  from  within  other  data  type  defini¬ 
tions. 


primitive  operation :=  typename^  "="  " ("  typename^ " 

where  typename^  is  a  data  type  name  in  lower-case  characters 
and  k  is  an  integer,  possibly  empty,  and  is  a  primitive 
operation  name. 

(3)  An  assertion  (about  a  type)  in  AXES  is  a  true  statement  about 
the  equality  of  two  ACSs  in  which  all  the  nodes  are  operations. 
Each  ACS  is  defined  in  terms  of  primitive  operations  of  the  data 
type  of  interest  or  of  previously  characterized  primitive  opera¬ 
tions  on  another  data  type.  The  arguments  of  a  mapping  can  be 
values  of  a  type  as  an  alternate  notation  for  the  KC0NsTANT  opera¬ 
tion  (Section  8.0)  or  bound  variables.  The  set  of  assertions 
(about  a  type)  completely  characterize  the  type  of  interest  (Ap¬ 
pendix  III)  . 


assertion  (about  a  type) : 


definition. 

A  n  _  ii 

F-Cexpj.")- 


def inition2 
*xp2 


ii  ,  n 
* 


where  expi  is  an  exp  in  terms  of  previously  characterized  or 
primitive  operations,  variables  that  represent  values  of  pre¬ 
viously  characterized  data  types  or  the  type  of  interest,  and 
values  of  previously  characterized  data  types  or  the  type  of 
interest;  F  is  an  operation  name;  definition^  is  in  terms  of  the 
same  objects  as  exp^;  and  either  F  or  at  least  one  of  the  opera¬ 
tions  of  exp^  are  primitive. 
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An  example  of  a  data  type  specification  is  data  type  STACK. 

DATA  TYPE:  STACK; 

PRIMITIVE  OPERATIONS: 

stack^  =  Push (stack2, integer^  ; 
stack^  =  Pop(stack2) ; 
integer^  =  Toplstac^); 

AXIOMS : 

WHERE  Newstack  IS  A  CONSTANT  STACK; 

WHERE  s  IS  A  STACK; 

WHERE  i  IS  AN  INTEGER: 

Top (Newstack)  =  REJECT; 

Top(Push(s,i) )  =  i; 

Pop (Newstack)  =  REJECT; 

Pop(Push(s,i) )  =  s; 

END  STACK; 

The  entire  set  of  statements  constitutes  the  definition  of  the 
type  STACK.  The  first  line  and  last  line  give  the  name  of  the 
abstract  type,  the  lines  between  "DATA  TYPE"  and  "AXIOMS"  are 
the  complete  set  of  primitive  operations  that  receive  or  define 
values  of  the  type  STACK. 

The  names  STACK  and  INTEGER  that  appear  within  the  primitive 
operations  are  the  names  of  types  (INTEGER  is  a  previously  de¬ 
fined  type;  STACK  is  the  type  we  are  defining).  Only  type  names  and 
primitive-operation  names  appear  within  the  primitive-operation 
list.  The  lines  following  the  word  AXIOMS  are  axioms,  or  asser¬ 
tions,  about  the  behavior  of  the  primitive  operations.  Any  actual 
implementation  of  the  primitive  operations  must  satisfy  these 
axioms.  If  it  does  not,  the  implementation  is  invalid  and  does 
not  meet  the  specification.  Note  that  this  method  of  specifying 
a  STACK  does  not  bias  the  final  implementation  toward  the  use 
of  any  particular  mechanism  such  as  linked  list,  array,  etc. 
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The  names  "i"  and  "s"  that  appear  within  the  axioms  represent  ataiy 
value  of  any  variable  of  the  required  type.  Because  "i”  is  de¬ 
clared  to  be  an  INTEGER  variable,  it  represents  values  of  INTEG35R 
variables.  Similarly , "s" represents  values  for  variables  of  type 
STACK.  On  the  other  hand,  "Newstack"  represents  a  particular 
value  that  "s"  can  represent. 

Within  a  set  of  axioms,  a  variable  of  a  given  data  type  can  be 
used  only  in  contexts  that  require  that  same  data  type. 

Each  axiom  must  be  true  for  all  possible  values  of  the  variables 
described.  For  example,  the  second  axiom  means  that  for  any 
STACK  s,  and  any  INTEGER  i,  the  resulting  values  of  the  nested 
operations  Top (Push (Stack, i) )  must  be  equal  to  the  value  i. 
(Pushing  i  onto  s  and  then  taking  the  top  item  off  of  the  STACK 
produced  by  the  Push,  must  yield  value  i.) 


Intrinsic  Types 


Because  certain  data  types  are  common  to  a  wide  range  of  system 
specifications,  they  are  predefined  by  AXES.  This  means  that 
the  system  designer  does  not  have  to  define  these  types.  For 
AXES,  Appendices  IV  and  V  contain  the  intrinsic  data  type  defini¬ 
tions  . 


intrinsic  types:  * 


f  boolean 

boolean  value  \ 

l  natural 

| 

natural  value  1 

] integer  | 

i  integer  value  1 

(rational  ' 

value:  * 

'rational  value  l 

) property  (of  T)| 

(property  (of  T) value  f 

[set  (of  T) 

h 

set  (of  T)  value  \ 

\  line 
* 

I 

line  value  j 

i  extrinsic  value  / 
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boolean  value: 


natural  value: 


integer  value: 


rational  value: 


{integer 

integer^ . integer2 


["E"  integer] 


property  {of  T) 

value:  :  =  "PROPERTY  OF"  t  "IN"  T" | "true 

val  exp^ 


set  (of  T)  value: 


!{value1,...)  | 

"SET  OF"  t  "IN"  t  "|"  true  val  exp^ 


line  value: 


*any  finite  string  of  symbols 
possibly  empty' 


Extrinsic  data  type  values  are  defined  as  "'CONSTANT'  T"  using 
a  declaration^  statement  (Section  9.0). 
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16.0  DERIVED  OPERATIONS 


In  AXES,  we  specify  the  behavior  of  an  operation  witJbout  speci¬ 
fying  its  decomposition  by  writing  it  as  a  derived  operation. 

The  meaning  of  a  derived  operation  can  be  determined  in  terms 
of  previously  characterized  operations  (i.e.,  derived  from 
primitive  operations  of  a  type) . 

In  AXES,  we  specify  a  derived  operation  implicitly  by  means 
of  assertions  (about  an  operation)  that  describes  the  behavior 
of  the  operation  with  respect  to  other  already-defined  operations. 
The  existence  of  a  derived  operation  of  some  types  mast  be  prov¬ 
able  mathematically  from  the  existence  of  the  primitive  opera¬ 
tions  and  the  axioms  of  those  types.  To  specify  a  desrived  opera¬ 
tion  in  AXES,  we  use  the  following  syntax. 

"DERIVED  OPERATION:”  y  "  =  "  D  "("  X  " )  ; 


declaration. . . 
assertion(about  D) . . . 


"END"  D 

where  x,y  are  variables  or  sets  of  variables  and  D  is  a 
derived  operation  name. 

(definition^  def  inifcion2 

assertion  (about  D)  :  =  jFj"  ("expjV  F2"  ("exp^)" 

where  is  D  or  an  operation  of  the  types  D  is  derived  from; 
exp^  is  an  exp  in  terms  of  the  derived  operation,  D,  ©r  opera¬ 
tions  of  the  types  D  is  derived  from  and  values  of  tlae  types  D 
is  derived  from;  definition^  is  in  terms  of  the  derived  operation 
D  or  operations  of  the  types  D  is  derived  from  ar.d  values  of  the 
type  D  is  derived  from.  For  example,  a  derived  operation  taken 
from  Appendix  IV  is 
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DERIVED  OPERATION:  integer3=IGCD (integer^ , integer^ ; 
WHERE  ARE  INTEGERS* 

Abs (IGCD(i1,i2) )  ■  GCD(Abs (i2,i2) ) ; 

SigndGCDdjyij))  =  True; 

END  IGCD; 
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17.0  RECURSION  VS.  ITERATION 


Because  AXES  does  not  permit  multiple  definitions  of  a  given 
variable,  the  common  control  statements  of  programming  languages 
have  no  meaning  in  AXES.  For  example,  a  statement  of  the  form 

WHILE  a<b  DO  ...  END; 

has  no  meaning  in  AXES  because  a<b  always  has  the  same  value. 

(The  values  of  a  and  b  cannot  change.) 

Traditional  control  statements,  such  as  WHILE,  are  normally 
used  to  express  functions  as  iterative  algorithms.  In  AXES, 
these  iterative  algorithms  must  either  be  expressed  using 
control  structure  definitions  or  written  as  recursive  func¬ 
tions  . 

The  following  text  shows  a  simple  iterative  algorithm  written 
in  PL/1: 

DO  WHILE (i,n) ; 
a (i)  =  F (b(i) ) ; 
i  B  g(i) ; 

END; 

In  AXES,  the  same  problem  is  expressed  using  functions  without 
giving  more  than  one  definition  of  any  variable. 

« 

This  PL/1  formulation  cannot  be  tested  for  interface  correctness. 
For  example,  we  do  not  know  if  a(i)  is  defined  more  than  once, 
or  if  a(i)  is  ever  defined.  This  uncertainty  could  have  serious 
consequences  on  system  implementation;  but  we  can  avoid  the 
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problem  altogether  in  AXES  by  formulating  the  function  differ¬ 
ently.  Suppose  we  wished  to  establish  the  values  that  "a" 
represents  where  a  -  (a^.-.a.). 

FUNCTION;  a  =  H(b); 

WHERE  a  =  (a1,a2);  WHERE  b  »  (b^^ ,b2 ) ; 

INCLUDE  =  F^b^  ALSO  a2  =  G(b2); 

EITHER  a2  =  KREJECT{lb2)  0THERWISE 

a2  =  H(2b2} 

PARTITION  OF  b2  IS  1b2  f  b2  m  REJECT, 

<ib2|b2  NOT  =  REJECT? 

END  H? 

The  control  map  for  function  H  is 


In  the  AXES  formulation,  any  size  data  structure  is  inherent 
in  the  specification,  however,  a  and  b  possess  the  same 
structure.  If  "a"  and  "b"  are  defined  as  variables  and  H  is  a 
primitive  operation  on  data  type  array,  then  the  above  speci¬ 
fication  can  be  expressed  simply  as  "a  =  H(b)". 
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18.0  CONCLUDING  REMARKS 

In  this  report  we  have  been  careful  to  differentiate  between  the 
name  of  a  object  and  the  object,  itself. 

In  AXES,  a  name  (variable)  always  represents  no  more  than  one 
object.  The  objects  are  members  of  a  hierarchy  whose  relation¬ 
ship  is  that  of  control.  AXES  syntax,  AXES  abstract  control 
structures,  AXES  abstract  data  types,  and  AXES  systems  are  all 
based  on  the  methodology  of  HOS.  In  this  version  of  AXES,  we 
have  concentrated  on  a  syntax  which  will  provide  a  basis  for  a 
system  to  be  explicitly  defined  in  such  a  way  or  to  be  automati¬ 
cally  analyzed  for  interface  correctness. 

In  the  future  we  hope  to  provide  more  building  blocks  (i.e.  user- 
defined  abstract  control  structures  and  abstract  data  types)  in 
order  to  facilitate  further  the  communication  between  users  in 
the  process  of  specifying  particular  systems  and  systems  in  gen¬ 
eral. 
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•*  A.  , 


APPENDIX  I 

PRELIMINARIES  OF  HOS 

* 

Trees  and  Functions 

Using  the  HOS  approach,  software  systems  can  be  developed  with 
the  aid  of  simple  mathematical  concepts  and  a  set  of  software 
engineering  axioms.  In  this  Appendix,  the  required  mathematical 
concepts  are  described. 

The  two  mathematical  concepts  required  in  order  to  describe  HOS 
are  the  tree  and  the  function.  The  tree  is  a  structure  comprised 
of  a  finite  number  of  nodes  which  are  connected  by  branches  as 
shown  in  Figure  AI-1. 


Figure  AI-1 

An  Example  of  a  Tree  Structure 

A  branch  may  be  interpreted  as  entering  a  node  {from  above  the 
node)  or  leaving  a  node  (from  below) .  The  unique  node  at  the 
top  of  the  tree  that  has  no  branches  entering  it  is  called  the 
root  of  the  tree.  A  node  that  has  no  branches  leaving  it  is 
called  a  leaf  of  the  tree.  It  should  be  noted  that  all  nodes 
other  than  the  root  have  exactly  one  entering  branch. 

A  root  is  considered  to  be  at  level  0  of  the  tree  (see  Figure 
.AT- 2)  .  As  one  starts  at  the  root  and  traverses  a  path  to  a  leaf, 

* 

Excerpted  from  Hamilton,  M.  and  Zeldin,  S,  "Integrated  Software 
Development  System/Higher  Order  Software  Conceptual  Description", 
Version  1,  Higher  Order  Software,  Inc.,  Cambridge,  MA,  Nov.  1976. 
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each  successive  node  defines  the  next  level  of  the  tree. 


root 


leaf  leaf 


Figure  AI-2 
Tree  Levels 


♦  level  0 

«•  level  i 
+  level  2 
level  3 


If  a  branch  leaves  node  A  (Figure  AI-3)  and  enters  node  B, 
then  node  A  is  the  parent  of  node  B,  and  node  B  is  an  offspring 
of  node  A.  (In  Figure  AI-3  node  C  is  also  an  offspring  of  node 
A.) 


Figure  AI-3 

Parent-Offspring  Relationship 

A  nodal  family  is  a  particular  parent  node  and  all  of  its  off¬ 
spring  (see  Figure  AI-4) . 

If  there  exists  a  sequence  of  nodes  n^ ,n2# . . . in^,  such  that  for 
every  i,  n^+1  is  an  offspring  of  n^,  then  each  n^+1  is  a  des¬ 
cendant  of  n^.  A  particular  parent  node  of  the  tree  together 
with  all  of  its  descendants  and  connecting  branches  is  the  sub¬ 
tree  defined  by  the  given  parent. 
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PARENT  NODE 

A  SUBTREE 


Figure  AI-4 
Tree  Substructures 

If  a  and  6  are  set  elements  (from  either  the  same  or  different 
sets),  then  "(a,  6)"  denotes  the  ordered  pair  consisting  of  a  and 
6  in  that  order.  (Thus,  the  ordered  pair  (a,  8)  is  not  the  same 
as  (8, a)  except  for  the  case  where  a  and  8  are  the  same  elements.) 

If  two  sets,  X  and  Y,  are  given,  and  "x"  and  My"  repi  sent  arbitrary 
elements  of  X  and  Y,  respectively  (i  e.,  "x"  and  "y"  are  variables), 
then  any  set  of  ordered  pairs  of  the  form  (x,y)  is  a  relation 
between  X  and  Y.  For  example,  if  X  =  {1,2 , 3 ,4 ,5, 6}  and  Y  «  {m, 
s,e,w},  then  one  possible  relation  between  X  and  y  is  R  **  {(4,m), 
(3,s),  ( 4  ,w)  }  . 

The  set  of  left  elements  of  the  relation  is  called  the  domain , 
and  the  set  of  right  elements,  the  range.  In  the  above  example, 
the  domain  is  {3,4},  and  the  range  is  {m,s,w}. 

A  relation  is  a  function  when  each  element  of  the  domain  has  only 
one  corresponding  range  element.  If  f  is  a  relation  between  X 
and  Y,  and  f  is  also  a  function,  then  we  say  that  "f  is  a  function 
from  X  into  Y"  (usually  written  y  “  f(x)) .  An  example  cf  a  func¬ 
tion  is 

f  =  {  (1,-a)  ,  (2,s)  ,  ( 4 ,m)  ,  (6,e)  } 
as  illustrated  in  Figure  AI-5. 

AI-3 


HIGHER  OROER  SOFTWARE,  INC  •  843  MASSACHUSETTS  AVENUE  .  CAMBRIDGE,  MASSACHUSETTS  02139  •  (617)  661-8900 


RANGE  OF  F 


DOMAIN  OF  F 


Figure  AX-5 

Illustration  of  a  Function  from  X  into  Y 

In  the  sections  that  follow,  the  variable  that  represents  the 
domain  elements  is  referred  to  as  the  input  variable,  and  the 
variable  that  represents  the  range-  elements  is  referred  to  as 
the  output  variable.  Individual  domain  and  range  elements  may 
be  called  inputs  and  outputs,  respectively. 

Modules  and  Nodal  Families 


In  HOS,  the  decomposition  process  for  a  system  results  in  a  tree 
structure.  At  the  start  of  the  decomposition  process,  the  en¬ 
tire  system  is  represented  by  the  root  of  the  tree  which,  hope¬ 
fully,  represents  the  requirements  for  the  system.  This  descrip¬ 
tion,  however,  has  many  implicit  (hidden)  requirements.  In  order 
to  explicitly  arrive  at  the  complete  description  of  the  require¬ 
ments  of  the  system,  the  root  is  decomposed  by  replacing  it  by 
a  nodal  family,  which  represents  the  decomposition  of  the  root. 
This  decomposition  process,  that  of  replacing  a  function  by  its 
nodal  family,  can  be  continued  until  the  entire  system  has  been 
explicitly  specified  to  whatever  detail  is  required  or  desired. 
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rjj 

-1 

I 

3 

It  may  turn  out  that  during  the  decomposition  process,  a  require¬ 
ment  is  shown  to  be  erroneous  or  missing.  In  such  a  case,  an 
iteration  of  the  system  description  is  required. 

The  parent  node  of  the  nodal  family  controls  its  offspring. 

When  referring  to  this  control  relationship,  the  parent  node  will 
be  called  a  module,  and  its  offspring  will  be  called  functions. 

The  offspring  of  the  nodal  family  are  the  functions  required  to 
perform  the  module’s  corresponding  funci^  i,  (MCF)  (i.e.,  the 
function  that  the  nodal  family  replaces. 

The  resulting  tree  represents  the  system  where  the  leaves  rep¬ 
resent,  in  an  abstract  machine  sense,  the  machine  "instructions" 
that  are  to  be  actually  performed;  the  intermediate  nodes  rep¬ 
resent  control  with  respect  to  the  performance  of  these  leaves. 

It  can  be  shown  that  the  HOS  axioms  provide  rules  for  the  way 
that  a  nodal  family  can  be  constructed  (HAM76)  . 
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AXIOMS  OF  HOS 


DEFINITION :  Invocation  provides  for  the  ability  to  perform  a  function. 

axiom  1 :  A  given  module  controls  the  invocation  of  the  set 

of  functions  on  its  immediate,  and  only  its  immediate, 
lower  level. 

DEFINITION:  Responsibility  Provides  for  the  ability  of  a  module  to 

produce  correct  output  values. 

AXIOM  2:  A  given  module  controls  the  responsibility  for 
elements  of  only  its  own  output  space. 

DEFINITION:  An  output  access  right  provides  for  the  ability  to  locate  a 
variable,  and  once  located,  the  ability  to  place  a  value  in  the 
located  variable. 

AXIOM  3:  A  given  module  controls  the  output  access  rights  to 
each  set  of  variables  whose  values  define  the 
elements  of  the  output  space  for  each  immediate 
and  only  each  immediate,  lower  level  function. 

DEFINITION :  An  input  access  right  provides  for  the  ability  to  locate 
a  variable,  and  once  located,  the  ability  to  reference  the 
value  of  that  variable. 

axiom  4:  A  given  module  controls  the  input  access  rights  to  each 

-  set  of  variables  whose  values  define  the  elements  of  the 

input  space  for  each  immediate,  and  only  each  immediate, 
lower  level  function. 

DEFINITION:  Rejection  provides  for  the  ability  to  recognize  the 

improper  input  element  in  that  if  a  given  input  element  is  not 
acceptable,  null  output  is  produced. 

AXIOM  5:  A  given  module  controls  the  rejection  of  invalid 
elements  of  its  own,  and  only  its  own,  input  set. 

DEFINITION:  Ordering  provides  for  the  ability  to  establish  a  relation 

in  a  set  of  functions  so  that  any  two  function  elements  are  comparable 
in  that  one  of  said  elements  precedes  the  other  said  element. 

AXIOM  6:  A  given  module  controls  the  ordering  of  each 

tree  for  the  immediate,  and  only  the  immediate, 
lower  level. 
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PROPERTIES  OF  THE  PRIMITIVE  CONTROL  STRUCTURES* 


FUNCTIONAL  DECOMPOSITION 


While  a  function  can  be  decomposed  in  many  ways,  the  HOS  axioms 
provide  rules  for  the  construction  of  nodal  families  (i.e.,  the 
decomposition  of  a  function).  From  the  axioms,  three  primitive 
control  structures  are  derived  which  are  used  for  functional  de¬ 
composition  (HAM76b) .  These  control  structures  are  composition, 
set  partition,  and  class  partition. 

Composition  is  illustrated  in  Figure  AII-1.  In  order  to  perform 
f^x),  the  function  roust  first  be  applied  to  x  which  results 
in  output  z.  z  then  becomes  an  input  to  f^  which  produces  the 
desired  range  element  of  the  overall  function  f^. 


y 


f2(x) 


Figure  AII-1:  An  Example  of  Composition 


It  is  important  to  observe  the  following  characteristics  of  com¬ 
position  (characteristics  are  explained  with  respect  to  the  ex¬ 
ample  in  Figure  AII-1) : 

(1)  One  and  only  one  offspring  (specifically  f2  in  this  ex¬ 
ample)  receives  access  rights  to  the  input  data,  x,  from 
module  f^. 

(2)  One  and  only  one  offspring  (specifically  f^  in  this  ex¬ 
ample)  has  access  rights  to  deliver  the  output  data,  y, 
for  module  f^. 


*  Excerpted  from  Hamilton,  M.  and  Zeldin,  S .,  "Integrated  Software 
Development  System/Higher  Order  Software  Conceptual  Description", 
Version  1,  Higher  Order  Software,  Inc.,  Cambridge,  MA,  Nov.  1976. 
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(3) 


All  other  input  and  output  data  that  will  be  produced  by 
offspring  controlled  by  f^  will  reside  in  local  variables 
(specifically  "2"  in  this  example).  Local .variable,  "2", 
provides  communication  between  the  offspring,  f2  and  f^. 

(4)  Every  offspring  is  specified  to  be  invoked  once  and  only 
once  in  each  process  of  performing  the  parent  modules  cor¬ 
responding  function,.  (MCF)  . 

(5)  Every  local  variable  must  exist  both  as  an  input  vari¬ 
able  for  one  and  only  one  function  and  as  an  output  vari¬ 
able  for  one  and  only  one  different  function  on  the 

same  level. 

Additional  examples  of  composition  are  given  in  Figure  AII-2  and 
Figure  AII-3. 


fx(x) 


Figure  AII-2:  Composition  with  Three 
Functions  on  One  Level 


Figure  AII-3:  Multilevel  Composition 

1 
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Set  partition,  which  involves  partitioning  of  the  domain,  is 
illustrated  in  Figure  AII-4.  In  this  example,  the  set  which  com¬ 
prises  the  domain  is  partitioned*  into  two  subsets.  For  set 
partition,  only  one  of  the  offspring  will  be  invoked  for  each 
performance  of  the  MCF  at  ^  (the  determination  being  based  on 
the  value  of  "x"  received)  and  that  offspring  will  produce  the  re¬ 
quired  range  element  for  its  parent  module  when  it  is  performing. 


Figure  AII-4:  An  Example  of  Set  Partition 

The  following  characteristics  with  respect  to  set  partition  should 
be  observed: 

(1)  Each  offspring  of  the  module  at  fj  is  granted  permis¬ 
sion  to  produce  output  values  of  "y"- 

(2)  All  offspring  of  the  module  at  f^  are  granted  permis¬ 
sion  to  receive  input  values  from  the  variable  "x"  • 

(3)  Only  one  offspring  is  specified  to  be  invoked  per  input 
value  received  for  each  process  of  performing  its  MCF, 
i.e.,  only  one  offspring  has  a  state  change  for  a  given 
state  change  of  the  parent  module. 

(4)  The  values  represented  by  the  input  variables  of  an  off¬ 
spring's  function  comprise  a  proper  subset  of  the  domain 
of  the  function  of  the  parent  module. 

(5)  There  is  no  communication  between  offspring. 

T -  ... 

Partitioning  implies  the  subdivision  of  the  original  set  into 

non-overlapping  (i.e.,  mutually  exclusive)  subsets. 
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Alternative  approaches  to  the  set  partition  illustrated  in  Fig¬ 
ure  AII-4  are  presented  in  Figures  AII-5  and  AII-6. 


)  y 


f,(x  ) 

2  { x | x  <  0} 


Figure  AII-5:  Set  Partition  with  Three 
Functions  on  One  Level 


y  -  f(x) 


Figure  AII-6:  Multilevel  Set  Partition 

Class  partition  is  illustrated  in  Figure  AII-7.  While  set  parti¬ 
tion  involves  partition  of  the  domain  into  subsets,  class  parti¬ 
tion  involves  partition  of  the  domain  variables  into  classes  and 
the  partition  of  the  range  variables  into  classes.  In  the  ex¬ 
ample,  it  is  assumed  that  the  domain  variable  has  an  associated 
data  structure  comprised  of  two  parts,  "x^  and  "x2".  Likewise, 
the  range  variable  has  an  associated  data  structure  with  the  same 
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number  of  classes  as  the  domain's  data  structure.  (As  an  example 
of  such  a  structure,  consider  the  domain  to  be  the  complex  nunsbers? 
the  range  to  be  polar  coordinates.  Then,  for  a  given  value  of:  the 
domain  variable  (i.e.,  a  given  complex  number),  "x^"  would  represent 
its  real  part  and  "x^"  its  imaginary  part.  Consequently,  the  'vari¬ 
able  is  partitioned  into  two  separate  classes,  "  x  ^  "  and  "x2",  such 
that  elements  associated  with  "x^'  are  the  input  elements  that,  one 
offspring  can  access  and  the  elements  associated  with  "x2"  are  the 
input  elements  that  the  other  offspring  can  access.  The  range 
structure  is  partitioned  in  a  similar  manner. 


Figure  AII-7:  An  Example  of  Class  Partition 

The  following  characteristics  with  respect  to  class  partition 
should  be  observed. 

(1)  All  offspring  of  the  module  at  f  are  granted  permissio.-n 
to  receive  input  values  taken  from  a  partitioned  vari¬ 
able  in  the  set  of  the  parent  MCF  domain  variables,  suich 
that  each  offspring's  set  of  input  variables  are  non¬ 
overlapping  and  all  the  offspring  input  variables  col¬ 
lectively  represent  only  its  parent's  MCF  input  vari¬ 
ables. 

(2)  All  offspring  of  the  module  at  f  are  granted  permission 
to  produce  output  values  for  a  partitioned  variable  in 
the  set  of  the  parent  MCF  range  variables,  such  that 
each  offspring's  set  of  output  variables  are  non-over  — 

I  lapping  and  all  the  offspring's  output  variables  col¬ 

lectively  represent  the  parent  MCF  output  variables. 
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(3)  Each  offspring  is  specified  to  be  invoked  such  that  for 
each  change  in  state  of  its  parent,  all  offspring  under¬ 
go  a  state  change. 


(4)  There  is  no  communication  between  offspring. 


AII-6 


HIGHER  ORDER  SOFTWARE,  INC  ■  843  MASSACHUSETTS  AVENUE  ■  CAMBRIDGE,  MASSACHUSETTS  02139  •  (617)  661-8900 


appendix  III 


ALGEBRAIC  SPECIFICATION  OF  ABSTRACT  DATA  TYPES 

by  S.  Cushing 


HIGHER  ORDER  SOFTWARE,  INC  •  843  MASSACHUSETTS 


AVENUE  .  CAMBRIDGE,  MASSACHUSETTS  02139  .  (617)  661-8900 


APPENDIX  III 

ALGEBRAIC  SPECIFICATION  OF  ABSTRACT  DATA  TYPES 

An  algebra  is  an  ordered  pair  [z,q]  ,  where  Z  is  a  non-empty  class 
of  non-empty  sets,  and  in  is  a  non-empty  class  of  operations  on 
the  grandmembers  (i.e.,  members  of  members)  of  Z.  The  members 
of  Z  are  called  categories1  of  the  algebra,  and  the  members  of 
0)  are  called  the  primitive  operations  of  the  algebra.  A  parti¬ 
cular  algebra  can  be  specified  by  giving  a  category  specifica- 

2 

tion,  an  operational  specification,  and  an  axiom  specification. 

A  category  specification  lists  or  defines  the  members  of  Z.  An 
operational  specification  gives  the  domains  and  ranges  of  the 
members  of  oj  as  Cartesian  products  of  the  members  of  Z.  An 
axiom  specification  is  a  non-empty  set  of  formal  statements  that 
characterize  the  interactive  behavior  of  the  members  of  u  and 
the  grandmembers  of  Z.  Algebras  can  be  classified  according 
to  the  constraints  that  we  choose  to  put  on  one  or  more  of  their 
category,  operational,  or  axiom  specifications. 

An  algebra  [Z,a)]  is  said  to  be  homogeneous,  if  Z  contains  exactly 

one  non-empty  member.  The  most  familiar  kind  of  homogeneous 

algebra  is  probably  the  group.  A  non-empty  set  G  is  said  to  be 

a  group  with  respect  to  a  binary  operation  Mult,  called  the  group 

3 

multiplication,  defined  on  G,  if  (1)  G  is  closed  under  Mult  , 

(2)  Mult  is  associative,  (3)  there  is  an  element  in  G  that  is 
neutral  with  respect  to  Mult,  and  (4)  every  element  of  G  has  an 
inverse ,  which  produces  the  neutral  element  under  Mult  (c.f. 

(FUN7 4 ) ) .  We  can  specify  a  group  G  formally  as  a  homogeneous 
algebra  as  follows: 

^Birkhoff  (BIR70)  and  Guttag  (GUT75)  call  these  phyla.  The  cate¬ 
gories  or  phyla  of  a  type  algebra,  which  we  will  consider  later, 
we  will  call  types. 

2 

Guttag  (GUT75)  calls  this  the  syntactic  specification,  but  this 
term  is  somewhat  misleading. 

"*The  uniqueness  of  the  image  under  Mult  is  also  required,  but  this 
is  guaranteed  by  specifying  Mult  as  a  mathematical  function ,  i.e., 
mapping,  as  in  (i,2). 
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( I )  Group  G  =  [l ,  o]  : 


(1) 

(2) 

(3) 


2 :  G ,  Neut  E  G 
w:  Mult:  G  x  G  ■+•  G 

Inv:  G  -*•  G 

Axioms:  1.  Mult (g^. Mult (g2 , ) )  = 

2.  Mult(Neut,g)  =  g 

3.  Mult (g, Neut)  =  g 

4.  Mult (g, Inv (g) )  =  Neut 


MultCCMult(g1,g2)  ,g3) 


In  this  example,  (1)  is  the  category  specif icatictn  of  the  group 
G,  (2)  is  its  operational  specification,  and  (3)  iis  its  axiom 
specification. 


The  category  specification  (1)  says  that  the  algebra  G  contains 
exactly  one  set  G  and  that  there  is  an  element  Neuit  in  G.  The 
operational  specification  (2)  says  that  the  algefcara  g  contains 
two  primitive  operations.  The  first  of  these  (MulL-t)  produces  a 
member  of  G  from  an  ordered  pair  of  members  of  G,  and  the  second 
(Inv)  produces  a  member  of  G  from  a  member  of  G. 


The  axiom  specification  (3)  specifies  the  interactive  behavior 
of  the  members  of  the  set  specified  in  (1)  and  the  primitive  op¬ 
erations  specified  in  (2) .  Every  axiom  should  be  interpreted 
as  being  universally  quantified  over  each  of  its  tree  variables. 
Axiom  1  says  that  Mult  is  an  associative  operatic^..  Axioms  2 
and  3  taken  together  say  that  Mult  has  no  effect,  :if  Neut  is  one 
of  its  arguments.  These  axioms  are  often  combined  as  a  single 
axiom  of  the  form: 

(4)  Mult  (Neut,g)  =  Mult  (g,Neut)  =  g, 

but  we  have  given  them  as  separate  axioms  to  ensuxre  that  every 
axiom  uniformly  contains  exactly  one  equality  symbol.  Axiom  4 
says  that  Mult  maps  every  member  of  G  and  its  inverse  onto  the 


AIII-2 

HIGHER  ORDER  SOFTWARE,  INC  •  843  MASSACHUSETTS  AVENUE  •  CAMBRIDGE,  MASSACHUSETTS  02139  •  (617)  661-8900 


neutral  element.  Together  Axioms  1-4  provide  the  primitive 
operations  in  o>  with  the  properties  required  to  make  the  set  in 
l  a  group. 

Other  familiar  examples  of  homogeneous  algebras  are  the  modules, 

4 

rings,  and  fields.  A  group  is  said  to  be  a  module,  also  called 

an  Abelian  group,  with  respect  to  its  group  operation,  if  that 

5 

operation  is  commutative  .  A  ring  is  a  non-empty  set  on  which 
two  operations.  Sum  and  Mult,  are  defined  such  that  it  .is  a  module 
with  respect  to  Sum,  and  Mult  is  associative  and  distributive  in 
both  directions  over  Sum.  A  field  is  a  ring  in  which  Mult  is 
commutative  and  every  element  other  than  the  neutral  element  with 
respect  to  Sum  has  an  inverse  with  respect  to  Mult. 

We  can  formalize  these  notions  very  easily  in  terms  of  the 
framework  being  developed  here.  To  get  a  module  we  simply  add 
the  axiom: 

(5)  Mult  (g1,g2)  =  Mult  (g2,g1) 

To  get  a  ring,  we  first  replace  "Mult"  throughout  (I)  and  Axiom  5 
with  "Sum",  "Neut"  with  "Zero",  and  "Inv"  with  *Opp",  meaning 
opposite.  These  names  are  changed  simply  to  bring  them  more  in 
line  with  our  intuitive  interpretation  of  Sum  as  a  kind  of  ad¬ 
dition.  We  also  replace  "G”  with  ,  "G"  with  "R",  and  "g" 
with  "r".  Then  we  put  "Mult"  back  into  (2),  we  put  Axiom  1  back 
into  (3),  and  we  add  the  two  axioms 

Mult  (r1,Sum(r2,r3) )  =  Sum  ,Mult(r1,r2)  ,  Mult  (r^,!^)) 

Mult  (Sum(r1,r2)  ,r3)  =  Sum  Mult ,r3)  ,  Mult  (r2,r3)). 

4 

It  should  be  emphasized  that  this  mathematical  use  of  the  term 
"module"  is  entirely  unrelated  to  what  is  meant  by  the  term 
"module"  in  systems  analysis,  particularly  in  HOS.  We  use  it  here 
only  as  an  example  and  will  not  use  it  outside  of  this  Appendix. 

^Modules  are  customarily  written  with  additive  operations,  like 
Sum,  but,  strictly  speaking,  any  Abelian  group  is  a  module,  since 
the  name  of  any  particular  operation  is  arbitrary.  See  Note  4. 
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This  gives  us  the  following  specification  for  a  ring: 

Ring  R  -  [E  ,  w] 

L:  R,  Zero  e  R 

u):  Sum:  R  x  R  R 

Opp:  R  R 

Mult:  R  X  R  -*■  R 

Axioms:  1.  Sum(r^,Sum(r2,r3))  =  Sum(Sum(r1,r2)  ,r3) 

2.  Sum ( Zero, r)  =  r 

3.  Sum(r,Zero)  =  r 

4.  Sum(r,  Opp(r))  =  Zero 

5.  Sum(r^,r2)  =  Sum(r2,r^) 

6.  Mult  (r ^ , Mult (r 2 , r3) )  =  Mult(Mult (r^,^)  ,r3) 

7.  Mult (r^, Sum (r2,r3) )  =  Sum (Mult(rlfr2) ,  Mult(r^,r3)) 

8.  Mult^Sumfr^rj)  ,r3)  =  Sum (Mult (r^, r3) ,  Mult(r2,r3)) 

If  we  put  Inv:  R  -*■  R  back  into  our  operational  specification, 
add  the  constant  value  Unit  to  R,  add  the  axioms: 

9.  Mulf(r^,r2)  =  Mult(r2,r^) 

10.  Mult(r,Unit)  =  r 

11.  Inv (Zero)  *  REJECT 

12.  Mult (r, Inv  (r) )  =  K^.^r)  AND  KREJSCT(2r) 

PARTITION  OF  r  IS 

1  2 
r|r  ^  Zero  and  rjr  =  Zero 
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to  our  axiom  specification,  and  remove  Axiom  8,  because  Axiom  9 
makes  it  superfluous,  we  get  a  formal  specification  of  the  fields 
as  homogeneous  algebras. 

The  REJECT6  value  in  Axiom  11  is  an  object  that  we  assume  to  be 
an  "invisible"  member  of  every  category.  Any  function  that  con¬ 
tains  REJECT  as  an  argument  automatically  has  REJECT  as  its  value, 
no  matter  how  deeply  embedded  the  REJECT  argument  may  be.  In 
Axiom  12  we  also  have  the  universal  primitive  operation 
defined  on  every  type  T,  that  produces  the  output  REJECT  for  any 
input  and  the  universal  primitive  operation  Kyn^t  that  produces 
Unit  as  output  for  any  input  (c.f.  M.  Hamilton  and  S.  Zeldin, 

"AXES  Syntax  Description",  Higher  order  Software,  Inc.,  Cambridge, 
MA,  Dec.  1976,  Section  8.0).  The  REJECT  value  is  useful  because 
it  enables  us  to  avoid  complicating  the  operational  specifications 
of  particular  algebras  and  the  definition  of  algebra  itself. 
Without  the  REJECT  value,  we  would  have  to  specify  the  operation 
Inv  as : 

Inv:  R  -  {Zero}  R, 

violating  our  prescription  that  the  domains  and  ranges  in  the 
operational  specifications  of  the  members  of  w  are  always  Car¬ 
tesian  products  of  the  members  of  E.  We  could  keep  this  pre¬ 
scription  without  the  REJECT  value  only  by  allowing  members  of 
a)  to  be  mathematical  partial  functions  (operations)  ,  significantly 
complicating  our  notion  of  algebra. 

An  algebra  which  is  not  homogeneous  is  said  to  be  heterogeneous. 

An  algebra  [E,u)jis  heterogeneous  if  E  contains  more  than  one  mem¬ 
ber.  The  most  familiar  heterogeneous  algebras  are  the  vector 
spaces.  A  non-empty  set  V  is  said  to  be  a  vector  space  over  a 
non-empty  set  S,  if  (1)  V  is  a  commutative  group  with  respect 
to  an  addition  operation  VSum  defined  on  it,  (2)  S  is  a  field 
with  respect  to  addition  (Sum)  and  multiplication  (Mult)  opera¬ 
tions  defined  on  it,  (3)  there  is  an  operation  SMult,  meaning 

6Guttag  (GUT75)  calls  this  the  "error"  value,  but  "error"  has 
overly  restrictive  connotations.  "REJECT"  connotes  only  tne 
fact  that  a  "normal"  output  is  not  produced,  not  that  a  genuine 
error  has  occurred. 
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scalar  multiplication,  defined  on  both  V  and  S  which  is  associa¬ 
tive  and  distributive  over  both  VSum  and  Sum,  and  which  has  the 
unit  element  of  Mult  as  its  own  unit  element. 

Formally,  we  get  the  following  specification  of  the  vector  spaces 
as  heterogeneous  algebras: 

Vector  Space  v  =  [E,w] 

I :  V,  VZero  e  V 

S,  S  ?  V,  Zero  e  S,  Unit  e  S 


w :  VSum 
VOpp 
Sum 
Opp 
Mult 
Inv 
SMult 


V  X  V  +  V 

V  V 

S  x  S  -+■  S 

s  -  s 

S  X  s  s 

s  +  s 

S  x  V  +  V 


Axioms:  1.  VSum  (v^,  vSum(v2,v3)  )  =  VSum  (vsum(v1#v2)  ,v3) 

2.  VSum  (VZero, v)  =  v 

3.  VSum  (v, VZero)  -  v 

4.  VSum  (v, VOpp (v) )  =  VZero 

5.  VSum  (v1rV2)  =  VSum  (Vj.v^ 

6.  Sum  (s1,Sum(s2, s3) )  *  Sum  (Sum(s1,s2) ,s3) 

7.  Sum  (zero,s)  =  s 

8.  Sum  (s,Zero)  =  s 

9.  Sum  (s,Opp(s))  =  Zero 
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10.  Sum  (s1,s2)  =  Sum  (s^s^ 

11.  Mult  (s1,Sum(s2,s3) )  =  Sum(Mult  (s^  ,s2)  ,  Multfs^Sj)) 


12.  Mult(s^,s2)  =  Mult(s2,s^) 

13.  Mult(s1,Mult(s2>s3) )  =  Mult(Mult(s1,s2) ,s3) 

14.  Mult(Unit,s)  =  s 

15.  Inv(Zero)  =  REJECT 

16.  Mult (s , Inv (s) )  =  KUnifc(1s)  AND  KREJ£CT(2s) 

PARTITION  OF  S  IS 

*s|s  ?  Zero 

2  i 

s | s  =  Zero 

17.  SMult (Unit, v)  =  v 

18.  SMult (s ,VSum(v3,v2) )  =  VSum (SMult (s, v^) ,  SMult(s,v2)) 

19.  SMult (Sum(s1,s2) ,v)  =  VSum  (SMult  (s-^v) ,  SMult(s2,v)) 

20.  SMult(Mult(s1,s2)  ,v)  =  SMult  (s^  SMult  (s2  ,v) ) 

Axioms  1-5  say  that  V  and  its  operations  comprise  ar.  additive 
Abelian  group7.  Axioms  6-10  say  that  S,  Sum,  Zero,  and  Opp  also 
constitute  an  additive  Abelian  group.  These  axioms  plus  Axioms 
11-14  say  that  S  and  its  operations  comprise  a  commutative  rinc,' 
and,  together  with  Axioms  15  and  16,  that  they  comprise  a  field. 
Axioms  17-20  characterize  the  operation  that  relates  S  and  V 
and,  together  with  tie  immediately  preceding  axiomatizations  of 
S  and  V,  say  that  S,V,  and  all  of  the  primitive  operations  speci¬ 
fied  in  the  operational  specification  comprise  a  vector  space. 

7 - 

Or  module,  but  see  Note  4. 
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As  specified,  the  algebra  v  =  [l,w)  is  a  heterogeneous  algebra, 
because  I  contains  two  distinct  categories.  If  we  remove  the 
stipulation  that  S  ^  V,  then  V  can  be  a  vector  space  over  itself 
and  the  possibility  that  v  could  be  homogeneous  is  opened  up. 

One  variety  of  algebra  that  has  proven  to  be  particularly  useful 
in  system  specification  and  that  is  incorporated  into  AXES  are 
the  type  algebras  of  Guttag  (GUT75) .  If  we  examine  closely  the 
algebras  we  have  seen  so  far,  we  realize  that  what  they  actually 
provide  are  schemata  for  structured  sets.  The  symbols  "G",  ”R" , 

"V",  and  "S"  in  the  algebras  G,  R,  and  v  are  set  variables,  not 
names  of  specific  sets.  Any  set  can  be  substituted  for  these 
variables,  provided  that  there  are  operations  definable  on  that 
set  that  satisfy  the  operational  and  axiomatic  specifications. 

It  follows  that  what  these  algebras  define  are  mathematical 
structures,  imposable  on  a  large  class  of  otherwise  different  sets. 

In  the  case  of  a  type  algebra  we  shift  our  perspective  and  view 
the  algebra  as  characterizing  a  particular  set.  One  of  the  cate¬ 
gories  in  Z  is  singled  out  as  the  type-of-interest  and  the  speci¬ 
fication  of  the  algebra  is  interpreted  as  an  implicit  definition 
of  the  kind  of  object  that  makes  up  the  members  of  the  type-of- 
interest.  The  categories  other  than  the  type-of-interest  are 
also  referred  to  as  types  in  a  type  algebra. 

Guttag  (GUT75),  for  example,  gives  an  algebraic  specification  of 
the  type  Natural  Number  that  can  be  formulated  in  our  framework 
as  follows: 

Type  Natural  Number  =  [l,w] 

I:  Natural  Number,  Zero  e  Natural  Number 

Boolean,  True  c  Boolean,  False  e  Boolean 

w:  Succ:  Natural  Number  -*■  Natural  Number 

?Zero?:  Natural  Number  Boolean 

?£qual?:  Natural  Number  x  Natural  Number  -*•  Boolean 

?>?:  Natural  Number  x  Natural  Number  ■*  Boolean 
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Axioms:  1.  ?zero?  (Zero)  =  True 


2.  ?Zero?  (Succ(n))  =  False 

3.  ?Equal?  (Zero,  zero)  =  True 

4.  ? Equal?  (Succ (n) , zero)  =  False 

5.  ?Equal?  (Zero,  Succ(n))  =  False 

6.  ?Equal?  (Succ(n)),  Succ(n1))=  ?Equal?  (n , ) 

7.  ?>?  (Zero, zero)  =  False 

8.  ?>?  (Succ (n) , Zero)  =  True 

9.  ?>?  (Zero,  Succ(n))  =  False 

10.  ?>?  (Succ(n),  Succ(n1))  =  ?>?  ( n , n 1 } 

Guttag  introduces  Zero  as  an  operation  that  maps  -the  empty  set 
onto  Natural  Number,  Zero:  0  +  Natural  Number,  saying  that  the 
emptiness  of  0  guarantees  that  a  unique  constant  rvalue  results. 
Actually,  however,  since  a  mapping  is  mathematically  a  set  of 
ordered  pairs  the  first  element  of  each  member  of  which  is  a  mem¬ 
ber  of  the  domain,  it  follows  that  having  an  empty  domain  guaran¬ 
tees  that  there  is  no  first  element  of  any  ordered  pair  and  thus 
no  ordered  pairs.  The  mapping,  viewed  as  a  set  oof  ordered  pairs, 
turns  out  to  be  the  empty  set  and  thus  not  really  a  mapping  at 
all.  If  there  is  no  input,  there  can  be  no  output,  unique,  con¬ 
stant,  or  otherwise.  Guttag' s  device  is  really  urnnecessary ,  in 
any  event,  because  all  we  have  to  do  is  to  state  -in  our  specifi¬ 
cation  of  l  that  Zero  is  in  Natural  Number.  Witfci  AXES,  this  is 
done  by  means  of  a  WHERE  statement,  as  we  will  se'e  in  Appendix  IV. 
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The  intent  of  the  operations  in  this  specification  should  be 
clear  from  their  names,  but  their  formal  meaning  is  provided 
entirely  by  their  operational  and  axiomatic  specifications. 

Guttag's  specification  of  the  hype  Natural  Number  is,  in  reality, 
inadequate,  because  it  omits  the  crucial  axiom  of  induction;  it 
still  serves  our  purpose,  however,  as  an  example.  We  will  see 
in  Appendix  IV  how  the  inadequacy  of  his  formulation  can  be 
remedied . 

In  this  example,  we  see  that  a  type  algebra  can  be  viewed  as 
defining  what  it  means  to  be  a  member  of  the  set  with  the  same 
name.  The  algebra  Natural  Number  defines  the  set  of  natural 
numbers.  An  object  is  a  natural  number  if  it  belongs  to  the 
set  characterized  by  the  respective  algebra.  The  primitive  op¬ 
erations  in  such  an  algebra  are  taken  as  being  defined  collec¬ 
tively  in  terms  of  their  interactive  behavior.  The  function 
Succ,  meaning  successor,  for  example,  has  meaning  only  with  re¬ 
spect  to  the  specification  of  Natural  Number  as  a  whole.  The 
specification  defines  all  of  its  primitive  operations  at  the 
same  time,  each  in  terms  of  the  others,  and,  through  them  it 
defines  its  type-of-interest .  What  makes  Natural  Number  a  type 
algebra,  in  contrast  to  the  general  algebras  we  saw  earlier,  is 
that  the  type-of-interest  is  taken  to  be  a  specific  set  of  a 
particular  kind  of  object  that  already  exists  in  the  world  (ox 
in  our  minds)  and  which  we  are  trying  to  make  intelligible. 

The  general  algebras  we  saw  earlier  define  mathematical  struc¬ 
tures  on  arbitrary  sets,  as  we  have  seen.  Guttag  (GUT75)  chax- 
acterizes  the  type  algebra  as  a  restricted  form  of  the  general 
heterogeneous  algebra  and  implies  that  the  type  Boolean  must  be 
presupposed.  Our  explicit  specification  in  Appendix  IV  of  Boolean 
as  a  homogeneous  type  algebra,  however,  shows  that  both  claims 
are  incorrect. 

The  usefulness  of  type  algebras  for  system  specification  lies  in 
the  need  to  maximize  the  degree  of  abstraction  in  the  specifi¬ 
cation  of  data  types.  The  customary  operational  means  of  speci¬ 
fying  abstract  data  types  requires  us  to  imbue  our  data  types 
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with  more  implementational  meaning  than  is  often  desirable.  If 
we  have  to  include  elements  of  implementation  in  specifying  an 
abstract  data  type,  then  we  may  unwittingly  rule  out  more  effi¬ 
cient  implementations  of  that  data  type  that  are  inconsistent 
with  those  elements.  With  HOS,  however,  we  are  able  to  divorce 
specification  entirely  from  implementation  and,  with  respect  to 
abstract  data  types,  we  manage  to  do  this  by  specifying  those 
types  algebraically,  rather  than  operationally.  Appendix  IV 
contains  a  list  of  algebraic  specifications  of  abstract  data 
types  that  are  included  in  AXES  as  intrinsic  types. 
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APPENDIX  IV 

TEE  INTRINSIC  TYPES  OF  AXES 

Although  AXES  provides  the  means  for  algebraically  specifying 
any  desired  abstract  data  type,  there  are  a  few  types  that  are 
of  sufficiently  general  usefulness  in  a  wide  variety  of  systems 
that  we  include  them  in  AXES  as  intrinsic  types.  These  types 
must  also  be  specified  algebraically,  of  course,  and  we  do  so, 
once  and  for  all,  in  this  Appendix.  In  all  we  provide  six  in¬ 
trinsic  data  types  in  AXES:  Booleans,  properties,  sets,  natural 
numbers,  integers,  and  rational  numbers.  The  Boolean  data  type 
automatically  solves  the  "boot-strap"  problem  for  abstract  data 
types,  because  it  can  be  characterized  as  a  homogeneous  algebra, 
i.e.,  entirely  in  terms  of  itself.  All  our  other  intrinsic  types 
presuppose  the  prior  characterization  of  type  Boolean  and  so  must 
be  characterized  as  heterogeneous  algebras.  Type  Property  pre¬ 
supposes  only  type  Boolean,  while  type  Set  and  type  Natural  all 
presuppose  type  Property.  Type  Integer  presupposes  type  Natural, 
and  type  Rational  presupposes  type  integer.  Our  reasons  for  not 
providing  the  real  numbers  as  an  intrinsic  data  type  will  be  dis¬ 
cussed  in  connection  with  our  algebraic  specification  of  the 
rationals.  All  our  intrinsic  types  will  be  specified  in  AXES 
syntax,  rather  than  i1*  the  strictly  mathematical  format  used  in 
Appendix  III.  In  this  Appendix,  AXES  statements  are  often  num¬ 
bered  for  purposes  of  discussion  (these  numbers  are  not  intended 
to  be  included  as  part  of  the  AXES  syntax)  . 

Type  Boolean  is  particularly  easy  to  characterize,  because  it 
contains  only  two  values,  true  and  false  (truth  and  falsity) . 

Since  I  contains  only  one  set  and  that  set  is  finite,  we  could 
identify  that  set  explicitly  by  simply  listing  its  members. 

This  frees  us  from  the  need  to  characterize  the  equality  rela¬ 
tion  on  type  Boolean,  which  we  could  not  do  without  a  prior 
characterization  of  type  Property .  Since  there  are  only  two 
distinct  Booleans,  which  we  explicitly  list  in  the  category 
specification,  we  can  always  tell  which  one  we  are  dealing  with 
simply  by  looking  at  it: 
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DATA  TYPE :  BOOLEAN ; 
PRIMITIVE  OPERATIONS: 


boolean^  =  And (boolean^, boolean2) ; 
booleanj  =  Not  (boolean^  ; 


AXIOMS : 

WHERE  True  IS  A  CONSTANT  BOOLEAN; 

WHERE  False  IS  A  CONSTANT  BOOLEAN; 

And (True ,True)  =  True;  1. 

And (True, False)  =  False;  2. 

And(False,True)  =  False;  3. 

And (False, False)  =  False;  4. 

Not (True)  =  False;  5. 

Not (False)  =  True;  6. 

END  BOOLEAN; 

In  this  algebra  we  specify  that  £'s  single  member  (contains  exactly 
two  elements,  true  and  false,  and  that  oj  contain®  exactly  two 
primitive  operations.  And  and  Not.  And  is  characterized  as  be¬ 
having  exactly  like  the  conjunction  operator  of  pmopositional 
logic  and  Not  is  characterized  as  behaving  like  tins  negation 
operator.  These  two  elements  and  these  two  operations,  as  axio- 
matized,  are  all  we  need  to  characterize  the  type  boolean  as 
an  abstract  data  type. 

Once  we  have  characterized  an  abstract  data  type  irn  terms  of  its 
categories  and  its  primitive  operations,  defined  collectively 
and  implicitly  through  its  axioms,  we  will  often  f7ind  it  useful 
to  define  other  operations  on  that  type.  Note  thait  the  categories 
of  the  type  algebra  Boolean  other  than  Boolean  its?elf  were  not 
listed  explicitly  in  the  AXES  specification  above,,  but  only  im¬ 
plicitly  through  their  appearance  in  the  PRIMITIVES  OPERATION 
SDe-if ication. 
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We  are  free  to  define  any  operation  we  want  on  an  already-defined 
type  as  long  as  the  operation  definition  is  consistent  with  the 
axioms  of  the  type.  New  operations  can  be  characterized  either 
as  operations  (c.f.  HAM76,  Section  8)  or  as  derived  operations 
(c.f.  HAM76,  Section  16).  An  operation  is  specified  in  AXES  ex¬ 
plicitly  in  a  form  that  is  directly  translatable  to  a  control 
map.  A  derived  operation  is  specified  implicitly  by  means  of 
assertions  that  describe  the  behavior  of  the  operation  with  re¬ 
spect  to  other  already-defined  operations.  Either  kind  of  opera¬ 
tion  could  be  written  as  a  control  map,  if  desired.  They  differ 
in  how  they  are  specified,  not  in  what  they  are.  What  distinguishes 
both  of  these  kinds  of  operations  from  primitive  operations  on 
their  data  type  is  that  their  existence  is  provable  mathematically 
from  the  existence  of  the  primitive  operations  and  the  axioms 
of  the  type.  If  an  operation's  existence  is  not  so  provable, 
then  adding  it  to  the  type  produces  a  new  type,  of  which  the  new 
operation  is  a  primitive. 


In  the  case  of  type  Boolean,  for  example,  we  will  often  find  it 
useful,  as  in  logic,  to  have  available  the  notions  of  disjunction, 
entailment,  and  sameness  of  truth-value.  We  can  introduce  these 
notions  as  operations  on  type  Boolean  by  means  of  the  following 
definitions : 


OPERATION:  b3  =  Ortb^b^; 

WHERE  b1,b2,b3  ARE  BOOLEANS; 

WHEREBY  b3  =  Not  (And  ( Not  (b^  ,Not(b2)  )  )  ; 
END  CO¬ 


OPERATION:  b3  *  Entails (b^,b2) ; 

WHERE  b1,b2,b3  ARE  BOOLEANS; 
WHEREBY  b3  *  Or(Not(b1) ,b2) ; 

END  Entails; 


OPERATION:  b3  =  Same(b1,b2) 

WHERE  b1,b2,b3  ARE  BOOLEANS; 

WHEREBY  b3  =  Or  (And(bx  ,b3)  ,And  (Notfb^  ,Not(b2) ) )  ; 

END  Same; 
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The  first  definition  defines  Or  in  terms  of  And  and  Not  in  a 
way  that  is  familiar  from  propositional  logic.  We  could  have 
introduced  it  as  a  primitive  operation  by  including  the  axioms: 

Or  (True, True)  =  True; 

Or  (True, False)  =  True; 

Or  (False, True)  =  True; 

Or  (False, False)  =  False; 

in  our  axiomatic  specification  of  type  Boolean,  but  this  would 
have  complicated  our  algebra  unnecessarily.  We  simply  do  not 
need  Or  to  characterize  the  Booleans  as  a  data  type.  Similarly, 
we  could  have  included  Entails  and  Same  as  primitive  operations, 
but  there  was  no  point  in  doing  so  as  long  as  we  can  define  them 
as  operations.  The  point  is  that  And  and  Not  are  all  we  need  to 
characterize  the  Booleans,  even  though  there  are  other  operations 
that  we  find  useful,  and  that  we  therefore  introduce  for  other 
purposes. 

It  should  be  noted  that  Same  is  an  equivalence  relation  on  type 
Boolean.  This  relation  coincides  with  equality,  because  we  al¬ 
ready  know  when  two  Booleans  are  the  same  or  distinct,  as  a 
result,  as  noted  above,  of  the  finiteness  of  the  single  set  in 
E.  If  this  were  not  the  case,  in  fact,  that  is,  if  equality  were 
not  automatically  given  to  us,  then  it  would  be  impossible  to 
write  axioms  for  type  Boolean,  because  the  "="  sign  would  be 
meaningless.  For  convenience  and  clarity,  we  will  sometimes 
use  "=",  and  a  few  other  symbols  like  "<",  in  the  conventional 
way,  rather  than  in  strictly  functional  notation,  once  we  have 
already  defined  them  functionally.  For  example,  it  may  be  sim¬ 
pler  to  write  **i^<i2"  in  an  axiom  for  type  Rational,  rather  than 
"I< (i^ , ij) . "  This  is  permissable,  because  we  will  already  have 
characterized  I<  (i.e.,  ,Jinteger-less  than")  in  our  specification 
of  type  Integer  (c.f.  HAM76  (Section  11)). 
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The  second  intrinsic  data  type  that  AXES  provides  is  that  of  pro¬ 
perties.  We  will  need  properties  in  characterizing  the  sets  as 
a  data  type.  Properties  are  basically  things  that  map  other  things 
onto  truth-values,  i.e.,  Booleans.  The  property  "prime",  for 
example,  maps  the  integer  2  onto  true,  3  onto  true,  and  4  onto 
false,  because  2  is  prime  and  3  is  prime,  but  4  is  not  prime. 

In  characterizing  properties  algebraically,  we  will  have  to  state 
what  kinds  of  things  the  properties  are  properties  of.  We  can 
do  this  by  including  a  type  parameter  "T"  in  our  category  speci¬ 
fication  and  treating  our  algebraic  specification  as  a  function 
of  r.  It  follows  that  our  algebra  for  type  Property  xs  really 
an  algebra  schema  depending  of  the  type  parameter  r  and  that  there 
is,  therefore,  a  distinct  type  Property  (of  T)  for  every  type  r. 

We  can  express  the  fact  that  properties  map  other  things  (i.e., 
t's)  onto  Booleans  by  introducing  a  function  that  maps  proper¬ 
ties  and  t's  onto  Booleans.  If  we  call  this  function  "Has”,  so 
that  "Has(P,t)"  is  true,  when  t  has  the  property  P,  then  we  must 
specify  that  Has  maps  properties  and  t's  onto  Booleans  in  a  way 
that  preserves  conjunctions  and  negations.  This  can  be  stated 
very  simply  in  terms  of  axioms.  To  define  equality  or  identity 
of  properties,  we  will  also  have  to  introduce  two  quantifier 
operations  Forall  and  Exists  (CUS76a) .  Properties  can  be  mapped 
onto  Booleans  by  combining  them  with  t's  via  the  Has  function, 
but  they  can  also  be  mapped  onto  Booleans  directly  via  these 
quantifier  functions.  Has  maps  P  and  t  onto  true,  if  t  has  the 
property  P.  Forall  maps  P  itself  onto  true,  if  every  t  has  the 
property  P.  Exists,  similarly,  maps  P  onto  true,  if  there  is  some 
t  that  has  P,  regardless  of  which  particular  t  that  is.  Once  we 
have  Forall  available  to  us,  it  will  be  a  simple  matter  to  specify 
when  two  properties  are  equal  (identical) . 

As  well  as  characterizing  the  relationship,  which  we  have  just 
discussed,  between  type  Property  (of  T)  and  type  Boolean,  we 
must  also  characterize  the  internal  structure  of  type  Property 
(of  T) .  Properties  constitute  a  Boolean  lattice  (FUN74) ,  so  we 
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must  include  the  axioms  for  a  Boolean  lattice  in  their  algebraic 
specification  as  a  data  type.  The  Booleans  also  constitute  a 
Boolean  lattice,  but  since  there  are  only  two  Booleans,  enabling 
us  to  list  the  values  of  their  primitive  operations  explicitly, 
we  can  prove  the  axioms  for  a  Boolean  lattice  from  that  explicit 
list  of  values.  For  properties,  however,  we  must  include  the 
axioms  for  a  Boolean  lattice  as  axioms  of  our  algebra,  because 
there  is  nothing  else  that  we  can  prove  them  from. 

The  foregoing  discussion  is  summarized  (and  elaborated)  in  the 
following  AXES  specification: 


DATA  TYPE:  PROPERTY (OF  T) ; 

PRIMITIVE  OPERATIONS: 

property3  =  Pand ( proper ty^ property 2)  ;  1. 

property3  =  Por (property^, property^ ;  2. 

property 2  =  Pnot (property^) ;  3. 

property3  =  Pentails(property^,property2) ;  4. 

boolean  =  Has (property, t) ;  5. 

boolean  =  Forall (property) ;  6. 

boolean  =  Exists (property) ;  7. 

boolean*  Ident (property^, property 2) ;  8. 


AXIOMS : 

WHERE  T  IS  SOME  TYPE; 

WHERE  P1»P2'P3  ARE  PR0PERTIES'* 

WHERE  t  is  a  T; 

WHERE  Nec  IS  A  CONSTANT  PROPERTY; 
WHERE  Contra  IS  A  CONSTANT  PROPERTY; 


pand(P1,P2)  =  Pand(P2,P1);  1. 
Por(P1#P2}  =Por(P2,P1);  2. 
Pand(PlfPand(P2,P3) )  =  Pand (Pand (P1 ,P2) ,P3) ;  3. 
Por(P1#Por (P2,P3) )  *  Por (Por(P1,P2) ,P3) ;  4. 
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Pand(p^ ,Por  (P1  ,P2) )  =P1; 

por  (P1,Pand(P1,P2) )  =  P^  6. 

PandfP^Por  (P2,P3) )  =  Por  (Pand^  ,P2)  ,  Pand ^ ,P3) )  ;  7. 

Por(P1,Pand(P2,P3) )  *=  Pand(Por (Px ,P2) ,  Por(P1,P3));  8. 

Pand(P,Pnot(P) )  =  Contra;  9. 

Por (P,Pnot (P) )  =  Nec;  10. 

Has (Nec, t)  =  True;  11. 

Has (Contra, t)  =  False;  12. 

Has (Pand(P1,P2) ,t)  =  And (Has (P1 , t) ,  Has(P2,t));  13. 

Has(Por(P1,P2) ,t)  =  Or (Has (P^, t) ,  Has(P2,t));  14. 

Has (Pnot(P) , t)  ■  Not (Has (P, t) ) ;  15. 

Forall (Nec)  =  True;  16. 

Exists (Contra)  =  False;  17. 

Forall(p)  =  Not (Exists (Pnot (P) ) ) ;  18. 

Exists (P)  =  Not(Forall(Pnot(P) ) ) ;  19. 

Entails (Forall (p) ,  Same(Has (P, t) ,True) )  =  True?  20. 

Entails (Same (Has (P,t) , True) ,  Exists(P))  =  True;  21. 

Ident(P^,?2)  =  And(Forall (Pentails (p^ ,P2) ) , 

Forall (Pentails (P2,P1) )) ;  22. 

END  PROPERTY (OF  T) 

OPERATION:  P3  =  Pentails (Px ,P2) ; 

WHERE  P1,P2,P3  ARE  PROPERTIES; 

WHEREBY  P3  «  Por (Pnot(P^) ,P2) ; 

END  Pentails; 


Axioms  l-TQ  in  this  specification  characterize  type  Property 
(of  T)  as  a  Boolean  lattice,  and  together  with  Axiom  22,  give  us 
the  internal  structure  of  the  type.  Axiom  22  is  essential  to 
the  internal  structure,  because  it  tells  us  when  two  properties 
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are  the  same  and  when  they  are  distinct.  The  value  Nec  is  the 


necessary  property,  which  every  t  has,  and  serves  as  the  unit 
element  of  the  lattice,  while  the  value  Contra  is  the  contradic¬ 
tory  property,  which  no  t  has,  and  serves  as  the  zero  element 
of  the  lattice.  Axioms  18  and  19  tell  us  that  Forall  and  Exists 
are  related  by  dual  negation,  which  is  definable  for  any  quanti¬ 
fier  (CUS76a,  CUS76b) .  Axioms  11-21  characterize  the  interface 
of  type  Property (of  T)  with  type  Boolean,  but  they  also  provide 
the  prerequisite  for  the  meaningfulness  of  Axiom  22.  We  thus  see 
the  sort  of  mutual  dependence  among  the  various  aspects  of  speci¬ 
fication,  in  this  case  between  the  internal  structure  and  the 
external  interface,  that  is  characteristic  of  algebraic  specifi¬ 
cation.  One  might  think  that  Ident  could  be  defined  as  an  opera¬ 
tion,  since  Axiom  22  defines  it  explicitly  in  terms  of  already 
defined  operations.  This  would  be  wrong  however,  because  a  notion 
of  identi-y  (equality)  is  essential  to  characterizing  the  internal 
structure  of  the  type.  Without  Axiom  22,  Axioms  1-10  would  liter¬ 
ally  be  meaningless,  because  we  would  have  no  clearly  specified 
interpretation  of  the  signs  that  occur  in  them. 

We  have  stated  (in  Axiom  22)  that  two  properties  are  identical 
if  they  are  mutually  entailing  for  every  member  of  the  type  whose 
members  they  are  properties  of,  that  is,  if  they  hold  of  exactly 
the  same  members  of  that  type.  Ultimately,  such  a  definition  is 
inadequate,  because  it  treats  certain  properties  as  identical 
which,  for  some  purposes,  should  not  be  considered  identical. 

The  two  conjunctive  properties,  "both  less  than  and  greater  than 
2"  and  "both  less  than  and  greater  than  100",  for  example,  are 
distinct  properties,  in  the  general  sense,  because  they  "say 
different  things"  about  the  objects  they  are  supposed  to  hold  of. 
By  our  definition,  however,  these  two  properties  are  identical 
and,  in  fact,  are  both  identical  to  Contra,  because  they  hold  of 
exactly  the  same  objects,  namely  none.  Since  we  are  interested 
in  properties  primarily  as  a  way  of  specifying  set  partitions 
in  system  specifications,  our  definition  of  identity  nevertheless 
suffices  for  our  purposes. 
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Given  the  way  we  have  characterised  properties  as  can  abstract  data 
type,  it  is  a  simple  matter  to  do  the  same  for  sets).  Because  of 
the  way  we  have  defined  identity  for  properties,  tine  type  Pro¬ 
perty  (of  T) ,  as  we  have  specified  it,  will  be  isomorphic  to  the 
type  Set  (of  T).  For  every  property  there  is  a  set:,  called  the 
extension  of  that  property,  which  consists  of  exact.ly  the  objects 
that  have  that  property.  Given  our  definition  of  piroperty  identity, 
this  mapping  from  properties  to  sets  is  one-to-one.  It  follows 
that  we  can  characterize  type  Set  (of  T)  isomorphicsally  to  type 
Property  (of  t)  in  terms  of  this  extension  mapping,  if  we  guarantee 
that  the  mapping  and  its  inverse  preserve  the  primittive  operations 
of  the  two  types.  This  is  done  in  the  follov/ing  specification: 


DATA  TYPE:  SET (OF  T) ; 

PRIMITIVE  OPERATIONS: 

set^  =  Inters(set^,set2) ;  1. 

set3  =  Unionise^, set2)  ;  2. 

set 2  =  Comp ( set ;  3. 

set  =  Extension (property) ;  4. 

property  =  Prop (set) ;  5. 

boolean  »  Element (t, set) ;  6. 

boolean  =  Subset (set^, set2)  ;  7. 

boolean  -  Equal (set^ ,set2) ;  8. 


AXIOMS : 

WHERE  S^,S2,S3  APE  SETS; 

WHERE  P  IS  A  PROPERTY; 

WHERE  Null  IS  A  CONSTANT  SET; 

WHERE  T  IS  SOME  TYPE; 

Inters  (s^,  s2)  »  Inters  (s2 , s^  ;  1. 

Union(s^,s2)  *  Union(s2,s^) ;  2. 

Inters(slfInters(s2,s3) )=  Inters (Inters (s^ , s2) ,s3) ;  3. 

Union(s^,Onion(s2,s3) )  =  Union (Union (s^,s2) ,s3) :  4. 

AIV-9 


HIGHER  ORDER  SOFTWARE,  INC  •  843  MASSACHUSETTS  AVENUE  .  CAMBRIDGE,  MASSACHUSETTS  02139  •  (617)  661-8900 


Inters (s^. Union (s^,s2) ) 
Union (s^# In ter s(s^,s2) ) 
Inter sts^, Union (s2,s3) ) 

Union (s^, Inters ( s2 , s^ ) ) 


*  Union(lnters (s1 ,s2)  , 
Inters (s^,s3) )  ; 

=  Inters(Union(s3,s2)  , 
Union(s^,s3) )  ; 


Inters (s, Comp (s) )  =  Null; 

Union ( s ,Comp (s) )  =  T; 

Extension (Prop (s) )  =  s; 
prop (Extension (P) )  =  P; 

Prop(T)  =  Nec; 

Prop (Null)  =  Contra; 

Prop(Inters (s3 ,s2) )  =  Pand (Propfs^) ,Prop(s2) ) ; 
Prop(Union(s1  rs2) )  =  Pordropd^)  ,  Prop(s2)); 
Prop(Comp (s) )  =  Pnot (Prop (s) ) ; 

Element(t,s)  =  Has (Prop (s) , t) ; 

Subset  (s^ s2)  =  Forall  (Pentails  (Prop (s^)  ,prop(s2) ) )  ; 
Equal(s1,s2)  *  And  (Subset  (s^, s2)  ,  Subset (s2, s^  )  ; 

END  SET (OF  T) ; 


5. 

6. 

7. 

8. 
9. 

10. 

11. 

12- 

13. 

14- 

15. 

16. 

17- 

18- 

19- 

20- 


f 


Axioms  1-10  in  this  specification  characterize  type  Set  of  (T) 
as  a  Boolean  lattice,  with  the  null  set  Null  as  the  zero  element 
and  the  universal  set  T  as  the  unit  element.  Axioms  11-17  define 
the  isomorphism  mapping  between  type  Set  (of  T)  and  type  Property 
(of  T) .  The  function  Extension  maps  a  property  onto  the  set  of 
elements  that  have  that  property,  and  the  function  Prop,  meaning 
"property**,  maps  a  set  onto  the  property  of  being  in  that  set- 
This  automatically  accounts  for  all  properties  because  of  our- 
definition  of  property  identity,  as  noted  above.  Axioms  18  and 
19  define  the  usual  notions  of  element  and  subset,  and  Axiom  20 
defines  equality  as  mutual  subset.  Something  is  in  a  set  if  it 
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has  the  property  that  corresponds  to  the  set  and  one  set  is  a  sub¬ 
set  of  a  second  if  everything  that  has  the  property  of  the  first 
has  the  property  of  the  second.  Two  sets  are  equal  if  each  is 
a  subset  of  the  other.  It  is  worth  noting  that  T  itself  is  a 
grandmeraber  of  1  in  this  case,  because  it  functions  as  the  unit 
element  of  the  algebra.  Upon  reflection,  we  realize  that  the 
set  Set  (of  T) ,  i.e.,  the  member  of  £,  as  opposed  to  the  algebra, 
turns  out  to  be  just  the  power  set  of  T  itself. 

Now  that  we  have  sets  and  properties  available  to  us,  we  can  con¬ 
struct  an  adequate  specification  of  the  natural  numbers  as  an 
abstract  data  type.  As  we  noted  in  Appendix  III,  Guttag's  speci¬ 
fication  of  the  type  Natural  Number  is  inadequate,  because  it 
leaves  out  the  crucial  axiom  of  induction.  This  axiom  can  be 
formulated  as  follows  (FUN74,  p.  72): 

If  a  property  P  of  the  natural  numbers  satisfies  the  follow¬ 
ing  two  conditions,  then  P  holds  for  every  natural  number: 

(1)  P  holds  for  0 

(2)  For  every  natural  number  n,  if  P  holds  for  n,  then 
P  holds  for  n'J 

where  n'  is  the  successor  of  n.  This  axioms  tells  us  that  we  can 
be  sure  every  natural  number  has  a  given  property,  if  we  know  that 
0  has  that  property  and  that  n+l's  having  it  follows  from  n's 
having  it,  for  every  n.  If  we  begin  at  0,  in  other  words,  and  go 
successively  from  each  natural  number  to  the  next,  then  we  eventu¬ 
ally  get  to  every  natural  number.  This  is  a  crucial  characteris¬ 
tic  of  the  natural  numbers  and  cannot  be  omitted  if  our  intent  is 
to  characterize  their  data  type  as  fully  as  possible. 

Since  we  now  have  the  facility  for  dealing  with  properties,  we 
could  formalize  the  axiom  of  induction  as  an  axiom  of  type  Natural 
Number  in  terms  of  the  members  of  type  Property  (of  Natural  Number), 
by  taking  r  =  Natural  Number,  in  other  words,  in  our  type  Property 
(of  T) .  It  turns  out,  however,  that  the  actual  formulation  of  this 
axiom  in  our  framework  is  very  complicated  and  somewhat  unintui¬ 
tive,  so  we  are  led  to  look  for  an  alternative  axiom  that  would 
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have  the  same  effect  as  the  axiom  of  induction.  Fortunately, 
this  purpose  can  be  served  by  a  characteristic  of  the  natural 
numbers  called  the  "well-ordering  principle",  which  states  that 
every  non-empty  set  of  natural  numbers  contains  a  least  element. 
The  axiom  of  induction  and  the  well-ordering  principle  are  logical 
ly  equivalent,  in  the  sense  that  each  can  be  derived  from  the 
other  within  the  context  of  the  other  axioms  for  the  natural  num¬ 
bers  (LAN67)  ,  so  we  are  free  to  take  either  one  as  one  of  our 
axioms.  The  well-ordering  principle  can  be  formulated  very  simply 
in  our  framework,  in  contrast  to  the  complexity  and  unintuitive 
character  of  the  axiom  of  induction,  so  we  will  adopt  it  to  com¬ 
plete  our  specification  of  type  Natural  Number. 

This  gives  us  the  following  AXES  specification: 


DATA  TYPE:  NATURAL; 

PRIMITIVE  OPERATIONS: 

natural2  ■  Succ (natural^ ;  1. 

boolean  =  ?Zero? (natural) ;  2. 

boolean  =  ?Equal? (natural^, narural2) ;  3. 

boolean  »  V>? (natural1,natural2) :  4. 

natural  *  Smin(set(of  naturals)^;  5. 


AXIOMS : 

WHERE  n,nx  ARE  NATURALS; 

WHERE  s  IS  A  SET (OF  NATURALS); 

WHERE  Zero  IS  A  CONSTANT  NATURAL; 

?Zero?(Zero)  *  True;  1. 

?Zero?(Succ (n) )  ■  False;  2. 

?Equal? (Zero, Zero)  =  True;  3. 

’Equal? (Succ (n) , Zero)  ■  False;  4. 

?Equal? (Zero, Succ (n) )  *  False;  5. 

?Equal? (Succ (n) , Succ (n^) )  =  ?Equal? (n,n^) ;  6. 

?>?(Zero,Zero)  «  False; 


7. 


?>? (Succ (n) , Zero)  =  True; 


8. 


?>? (Zero,Succ(n) )  =  False;  9. 
?>7  (Succ (n)  , Succ (r^) )  =  ?>(n,n1);  10. 
Element (Smin(s) ,  s)  =  True;  11. 
Entails (Element (n, s) ,  ?>? (n,Smin(s) ) )  =  True;  12. 
END  NATURAL; 


This  specification  is  identical  to  Guttag's  specification  of  type 
Natural  Number,  which  we  saw  in  Appendix  III,  except  for  the  new 
operation  Smin  and  the  two  new  Axioms  11  and  12.  Axioms  11  and 
12,  along  with  the  presence  of  Smin  in  u>,  provide  us  with  the 
effect  of  the  well-ordering  principle.  The  fact  that  the  Smin 
is  in  w  tells  us  that  every  set  s  of  natural  numbers  is  associated 
with  a  natural  number  Smin(s).  Axiom  11  tells  us  that  the  natural 
Smin(s)  is  an  element  of  s  and  Axiom  12  tells  us  that  Smin(s) 
is,  in  fact,  the  minimum  element  of  s.  This  specification,  then, 
completely  specifies  type  Natural  Number  as  the  type  of  what  we 
usually  think  of  as  the  natural  numbers. 

Now  that  we  have  a  full  specification  of  the  natural  numbers, 
we  can  define  operations  on  their  data  type.  Since  we  have 
already  characterized  equality  cf  natural  numbers  as  a  prim¬ 
itive  operation  of  our  data  type,  we  are  free  to  interpret  the 
sign  in  our  definitions  as  referring  to  that  equality.  We 
will  also  use  other  operations,  such  as  "And"  in  the  customary 
way,’ rather  than  the  more  complicated  functional  notations,  as 
long  as  these  operations  have  been  fully  characterized  (cf. 
section  10).  Some  of  the  following  operations,  such  as  Sum  and 
Prod,  meaning  sum  and  product,  respectively,  are  included  be¬ 
cause  of  their  general  usefulness;  others  are  included  because 
they  will  be  useful  in  specifying  later  data  types: 

DERIVED  OPERATION:  n3  =  Sumfn^nj); 

WHERE  n3,n2,n3  ARE  NATURALS; 

Sum(Zero,n2)  *  n2;  1. 

SumCn^Zero)  ■  n.;  2. 
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Sum(n^,Succ (nj) )  =  Succ (Sum(n^,n2) )  ; 

SumtSuccCn^)  ,n2)  *  SuccCSumtn^.nj) ) ;  4. 

END  Sum; 


DERIVED  OPERATION:  n3  =  ProdCn^nj); 

WHERE  n1#n2,n3  ARE  NATURALS; 

Prod(Zero,n2)  =  Zero;  1. 

Prod (n^, Zero)  =  Zero;  2. 

Prod(nlfSucc(n2) )  =  Sum  (Prod  (n^  ,n2)  ,1^)  ;  3. 

Prod (Succtn^)  ,n2)  *  Sum(Prod (nlfn2)  , n2)  ;  4. 

END  Prod; 


DERIVED  OPERATION:  n3  =  Ndif  f  (n^nj)  ; 

WHERE  nlfn2,n3  ARE  NATURALS; 

SumCn^^/Ndiff  (1n1,n2) )  *  n2;  1. 

Ndiff (2(n1,n2) )  =  REJECT;  2. 

PARTITION  OF  (nlfn2)  IS 
1  (nlfn2) 

(nl'n2) ln2>nl' 

END  Ndiff; 

DERIVED  OPERATION:  n3  =  Max(n1#n2); 

WHERE  n1,n2,n3  ARE  NATURALS; 

Max  1 (ni * n2)  *  n1;  1. 

Max  (nj^/nj)  »  n2;  2. 

PARTITION  OF  (n^nj)  IS 

^■(n^nj)  I  n2ln1» 

2(n1,n2) |n1<n2; 

END  Max; 
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DERIVED  OPERATION:  n3  =  Mintn^r^)? 

WHERE  n1>n2,n3  ARE  NATURALS; 

M,in(1(n1  ,n2) )  *  1n2; 

2  2 
Min(  , n2) )  =  i^? 

PARTITION  OF  (n^n^  IS 

(n^  ,n2)  |  n2<n^» 

2 

(n1#n2) |n1<n2; 

END  Min; 

DERIVED  OPERATION:  n3  =  Quot(n,,n2); 

WHERE  n1#n2,n3  ARE  NATURALS; 

Quot  1(n1,n2)  =  REJECT;  1. 

Sum (Prod (Quot  2(n1#n2),  Rem  2(n1#n2)))=  n^;  2. 

PARTITION  OF  (n^n^  IS 

i  * 

(n^n^  |n2  «  0, 

2(n1#n2) |n2  i  0; 

END  Quot; 

DERIVED  OPERATION:  n3  *  GCDtn^nj); 

WHERE  n1#n2,n3  ARE  NATURALS; 

Factor (GCD(n1#n2) ,n^)  «  True;  1. 

Factor (GCDtn^ ,n2) ,n2)  =  True;  2. 

Entails (And (And (Factor (n1#n2) , Factor (n^n.^) ) , Not (?Equal? (  n^ Zero) ) ), 
Factor (n1,GCD(n2,n3) ) )  =  Trua;  3. 

END  GCD; 

OPERATION:  n3  *  Rem(n^,n2) ; 

WHERE  n1,n2,n3  ARE  NATURALS; 

EITHER  n3  «  KREJECT(lnl'ln2)  0THERWISE 

EITHER  n3  «  IDENTIFY2 (2n1#2n2)  OTHERWISE 
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1. 

2. 


WHEREBY  n^  =  Rem(Ndiff  ^(n^,n2)  ,^n2; 

PARTITION  OF  (n^n^  IS 

1(n1,n2)  jn2  *  0, 

2 

(n^ # n2)  |n2  j*  0  AND  n1  <  n2, 

(n1#n2)  |n2  ^  0  AND  n2  <  n^ 

END  Rem; 

OPERATION:  b  =  Factor (n1#n2)  ; 

WHERE  n^nj  ARE  NATURALS; 

WHERE  b  IS  A  BOOLEAN; 

WHEREBY  b  =>  ?Equal? (Rem(n2  , Zero)  ; 

END  Factor; 

Derived  operations  Sum  and  Prod  give  us  addition  and  multiplica¬ 
tion/  respectively.  Derived  operation  Ndiff  gives  us  the  sub- 
traction  of  smaller  naturals  from  larger  ones.  Derived  opera¬ 
tion  Max  gives  us  the  larger  of  two  naturals,  derived  opera¬ 
tion  Rem  gives  us  division  (quotient)  with  remainder,  and  opera¬ 
tion  Factor  tells  us  when  one  natural  is  a  factor  of  another. 

Derived  operation  GCD  gives  us  the  greatest  common  divisor  of  two 
naturals  and  will  be  needed  in  the  specification  of  the  rationals. 

The  Integers  can  be  characterized  as  a  data  type  in  terms  of  the 
natural  numbers  by  recognizing  that  an  integer  is  just  a  natural 
number  with  a  sign.  Since  we  need  two  distinct  signs,  we  can 
take  our  signs  to  be  the  Booleans,  with  True  interpreted  as  plus 
and  False  interpreted  as  minus.  This  gives  us  the  following 
specification: 

DATA  TYPE :  INTEGER; 

PRIMITIVE  OPERATIONS: 

boolean  -  ?Iequal? (intege^ , integer2)  ;  1. 

boolean  «  ?I>?(integer1,integer2) ;  2. 

natural  =  Abs (integer) ;  3. 
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boolean  =  Sign (integer) ;  4. 
integer^  =  I sum (integer^, integer 2)  ?  5. 
integer ^  =  Iprod (integer^ , integer 2) ;  6. 
integer^  =  Iquot( integer integer 2) ;  7. 


AXIOMS: 

WHERE  i1#i,  ARE  NATURALS? 

WHERE  I zero  IS  A  CONSTANT  INTEGER; 

WHERE  lone  IS  A  CONSTANT  INTEGER; 

?lequal?(ilfi2)  =  OrtAndtPEqualTfAbsti^  ,Zero)  , 

?Equal? ( Abs ( i2) , Zero) ) , 

And ( ?Equal (Abs ( i^) , Abs ( i2) ) > 

Same ( Sign ( i^) , Sign (ij) ))) ;  1. 

?I>?(i^,i2)  =  (Same (Sign ( i^  , True)  &  Same ( Sign ( i2)  »True) 

&?>?(Abs(i1) ,  Abs (i2) ) ) 

!  (Same  (Sign  (i^)  , False)  &  Same  (Sign (i2)  , False) 

&?>? (Abs (ij) »Abs (i^) ) ) 

! (Same (Sign (i^) , True)  &  Same (Sign (i2) .False) ) ;  2. 

Abs(Isum(i^,i2) )  =  Sum(Abs(^i^) ,Abs(^i2) )  AND 

(Ndiff  (Max(Abs  ( 2i^)  ,  Abs(2i2)), 

Min(Abs ( 2i^) ,Abs (2ij) ) ) ;  3. 

PARTITION  OF  (i^ij)  IS 

1(i1#i2) |sign(i1)  -  Sign(i2) , 

2 ( il r  i2)  |Sign(i^)  SignU^)  ; 
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Sign(Isum(i1/i2) )  =  Signf1^)  AND  Signf2^)  AND  Sign(3i2) ;  4. 

PARTITION  OF  (i,,i2)  IS 

1(i1,i2) |Sign(i1)  =  Sign(i2)  , 

2  (i^ij)  jSignfij^)  ^  Sign(i2)  AND  Abs  ( i 2 )  _<  Abs(i1)  , 
3(i1#±2) |Sign(i1)  ^  Sign(i2)  AND  Abs(i1)  <  Abs(i2); 


Abs(Iprod(i1,i2) )  *  Prod  (Abs  (i^)  , Abs  (i2) )  ;  5. 

Sign(Iprod(i1,i2) )  =  Same  (Sign  (i^  ,Sign(i2) )  ?  6. 

Abs(Izero)  *  Zero;  7. 

Sign (I zero)  =  True?  8. 

Abs (lone)  =  Succ(Zero);  9. 

Sign (lone)  *  True;  10. 

Abs (Iquot (ilfi2) )  =  Quot(Abs(i x)  fAbs(i2) ) ?  11. 

Sign(Iquot(i1,i.2) )  =  SaroefSignfi^  ,Sign(i2) )  ;  12. 

END  INTEGER; 


DERIVED  OPERATION:  integer2  »  Iopp  ( integer^  ; 

WHERE  i  IS  AN  INTEGER? 

Sum(i,Iopp(i) )  =  izero? 

END  Iopp; 

OPERATION:  i3  «  Idif f  (^ , i2)  ? 

WHERE  i1,i2/i3  ARE  INTEGERS; 

WHEREBY  i3  »  SumU^IoppUj) )  ; 

END  Idiff; 

DERIVED  OPERATION:  integer3  »  IGCD ( integer integer2 ) ? 

WHERE  ilfi2  ARE  INTEGERS; 

Abs (IGCD(i^,i2) )  «  GCD(Abs(i1) ,Abs  (i2) ) ;  1. 

SigndGCDtij^ij))  »  True?  2. 

END  IGCD  ; 
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Axiom  1  is  complicated  by  the  fact  that  zero  cam  have  either  a 
plur  (true)  o/  minus  f false)  sign.  We  want  Sign;  to  be  a  mapping , 
however,  (i.t*.,  a  function  in  the  mathematical,  not  AXES,  seise, 
c.f.  HAM'/ 6  (Section  8.0))  so  we  assume  from  the  s^tart  that  plus 
zero  and  minus  zero  are  the  same  entity.  In  Axioora  8  we  say  zero 
has  r  plus  sign,  but  Axiom  1  tells  us  that  if  a  minus  zero  occurs, 
it  is  really  the  same  integer  as  plus  zero.  Two  integers  are  equal 
if  the.1  have  the  same  absolute  value  and  the  same  sign,  unless 
their  al*  =o]ute  values  are  both  zero.  In  that  case,  they  arc  equal 
regardless  of  their  signs. 

The  rational  numbers  can  be  characterized,  as  in  modern  arith¬ 
metic  theory,  as  ordered  pairs  of  integers  that  lhave  no  common 
factors.  Adopting  this  approach  we  get  the  following  specif i- 
cativ  »: 

DAT*  TYPE:  AALIONAL; 


PRIMITIVE  OPERATION: 

boolean  =  ?Requal?  (rational^, rational^  ?  1. 
boolean  *»  VR>? (rational. , rationale) ;  2. 
integer  *  Nuw (rational) r  3. 
integer  *  Dcnem (rational) ;  4. 
rational  *  Rsum (rational. , rational 2) ;  5. 
rational  ■  Rprca ( ration? 1^, rational 2) ;  6. 
boolean  =  Pos (rational) ;  7. 


AXIOMS: 

WHERE  r,rx,r2  ..RE  RATIONALS  ; 

WHERE  Rzero  IS  A  CONSTANT  RATIONAL; 
WHERE  Rone  IS  A  CONSTANT  RATIONAL; 


?Iequal? (Denom(r)  , I*;ero)  =  False;  1. 
IGCD (Abs (Num(r) ,Abs (Denom(r) ) ) )  =  lone;  2. 
Rprod (r,Denom(r) )  «  Num(r)  ;  3. 
?Requal?  (r^rj)  =  ?Iequal?  (Iprod  (Numfr^  ,Denora<r2)) )  . 

iprodtDenomtr^) ,Num(r2) ) ) ;  4. 
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NuiMRsiuMr^rj))  «  Iquot  (Cross  (r^r^  ,  IGCD(Abs  (Cross (r^r^  ) , 

Abs (Dprod (r^.rj) ) ) ) ; 

Denom(Rsrm(rlfr2))  -  Iquot  (Dprod  (r^rj)  ,  IGCD(Abs (Cross (r^) )  , 

Abs(Dprod(r1,r2) ) ) ) ; 

Num(Rprod(rlfr2))  =  Iquot (Nprod (rx,r2)  ,  IGCD(Abs  (Nprod  (rrr2) )  , 

Abs  (Dprod  (r^rj) ))) ;  7  * 

Denom(Rprod(r1,r2))  -  Iquot (Dprod ( r^ r 2)  ,  IGCD(Abs  (Nprod  (r^) )  , 

Abs ( Dprod ( r  x , r  2) ) ) ) ;  ®* 

5 . 

Nura(Rzero)  =  I  zero; 

10. 

Denom(Rzero)  *  lone; 

Pos(r)  *  And (Not (Equal (r, Rzero) ), Same (Sign (Num(r) ) , 

Sign(Denom(r) ) ) ) ;  12. 

?R>?(rlfr2)  =  Pos  (Rdiff  (r^rj) ) ;  12. 

END  RATIONAL; 

OPERATION:  r3  »  Cross (r^ ,r2) ; 

WHERE  r1,r2,r3  ARE  INTEGERS; 

WHEREBY  r3  »  Isumdprod  (Nurafr^  ,Denom(r2) )  , 

I prod (Denomtr^) ,Num(r2) ) ) ; 

END  Cross; 

OPERATION:  r3  =  Nprod (r^,r2) ; 

WHERE  *i'*2,r3  ARE  ^ NTEGERS ; 

WHEREBY  r3  *  Iprod (Num(r^) ,Num(r2) ) ; 

END  Nprod; 

OPERATION:  r3  ■  Dprod (r^,r2) ; 

WHERE  r1(r2fr3  ARE  INTEGERS; 

WHEREBY  r3  ■  Iprod (Denom(r^) ,Denom(r2) ) ; 

END  Dprod; 
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The  functions  Num  and  Denom  give  the  numerator  and  denominator 
of  a  "fraction"  in  the  "lowest  terms".  The  operations  Iquot 
and  GCD  are  used  throughout  the  axioms  to  guarantee  that  aums 
and  products  of  rationals  are  always  expressed  m  such  "lowest 
te-ms".  The  operations  Cross,  Nprcd,  and  Dpr -?d  are  just  useful 
abbreviations  that  .-.iatly  simplify  the  definitions  of  addition 
and  multiplication. 

DERIVED  OPERATION:  rational  =  Repp (rational^ ; 

WHERE  r  IS  A  RATIONAL; 

Rsum(r,Ropp(r) )  =  Rzero; 

END  Ropp; 

OPERATION:  r^  =  Rdif f  (r3,r2)  ? 

WHERE  r1,r2,r3  ARE  RATIONALS; 

WHEREBY  r3  =  Rsumtr^RoppUj) } ; 

END  Rdiff; 

DERIVED  OPERATION:  r«tional2  ■  Rinv(rational1)  ; 

WHE'-vE  r,r1#r-  ARE  RATIONALS; 

Rinv (Pzero)  =  REJECT; 

EITHER  Num(Rprod{r1)  ,Rinv(r?))  - 

0THEF.4ISE  NumtRprodCi  j^)  ,Rinv(r2) )  -  *Ione(2r); 

EITHER  Denom ( Rpr od (r, Rinv (r2.- ) )  =  KREJECT(1;r) 

OTHERWISE  Denom ( Rpr od(r, Rinv ( r 2) ) )  »  Kione(2r) ; 

PARTITION  OF  r  IS 
1r|r  «  0, 

2rjr  +  0; 

END  Rinv; 

OPERATION:  r3  «  Rdivfr^rj)  ; 

WHERE  ri»^2,r3  ARE  RATIONALS; 

WHEREBY  r3  =  Rprod (r^ , Rinv(r2) ) ; 

END  Rdiv; 
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These  are  the  usual  opposite,  difference,  inverse,  and  division 
for  the  rational  numbers. 


The  problem  of  specifying  the  real  numbers  presents?  a  serious 
problem  for  the  algebraic  specification  techniques  introduced 
by  Guttag  and  expanded  here.  We  have  already  seen,  how  Guttag's 
approach  must  be  expanded  to  give  an  adequate  specification  of 
the  natural  numbers.  A  complete  account  of  the  natural  numbers 
requires  an  axiom  equivalent  to  the  axiom  of  induction  and  well¬ 
ordering  principle  and  such  an  axiom  cannot  be  formrulated  without 
a  specification  of  properties  or  sets  as  abstract  dtata  types,  or 
some  equivalent  modification  of  Guttag's  approach.  In  the  case 
of  the  reals  we  encounter  a  similar  situation.  The  principal 
reason  for  introducing  the  real  numbers  in  mathematiics  is  to 
fill  in  the  "holes,"  so  to  speak,  in  the  set  of  ratiionals  visual¬ 
ized  as  a  "line."  Speaking  somewhat  more  formally,  there  exist 
sequences  of  rationals  that  seem  for  all  the  world  aas  if  they 
"ought"  to  converge,  but  for  which  there  is  no  rational  to  which 
they  do  converge.  The  reals  are  introduced  to  provixde  limits 
for  these  otherwise  non-convergent  sequences.  Spealking  still 
more  formally,  we  introduce  the  following  definitions,  where  K 
is  the  set  of  rationals  (actually,  any  ordered  fields)  (LAN67 , 
pp.  123-4 j : 

A  sequence  {xn}  in  K  is  said  to  be  a  Cauchy  seciuence  if 
given  an  element €>0  in  K,  there  exists  a  posit-ive  inte¬ 
ger  N  such  that  for  all  integers  m,  -i  >  N  we  hav/e 


An  ordered  field  ii:  which  every  Cauchy  sequence  converges 
is  said  to  be  complete. 

The  principal  formal  difference  between  the  rationale  and  the 
reals  is  that,  while  the  rationals  constitute  an  ordtered  field, 
the  reals  constitute  a  complete  ordered  field.  The  obstacle  we 
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face  in  trying  to  axiomatize  the  reals  in  our  modified  Guttag 
framework  is  that  there  seems  at  this  time  to  be  no  clearly 
satisfactory  way  to  formulate  this  notion  of  completeness  within 
that  framework. 

In  retrospect,  although  we  may  eventually  find  a  way  to  formu¬ 
late  completeness  within  our  framework,  it  may  be  that  our  pre¬ 
sent  inability  to  do  so  is  really  a  virtue,  rather  than  a  defect 
of  our  framework.  The  real  numbers  have  always  been  really  a 
convenient  myth  with  respect  to  computer-based  systems.  Although 
we  often  talk  in  terms  of  real  numbers,  the  finite  character  of 
our  machines  (and  of  ourselves)  always  forces  us,  in  the  end, 
to  "round-off"  our  real  numbers  and  approximate  them  by  rationals. 
The  problems  that  arise  as  a  result  of  this  situation  are  widely 
known  (e.g.  see  (ZEL73) ) .  This  suggests  that  our  present 
inability  to  formulate  completeness  (and  thus  the  reals)  in 
the  framework  of  type  algebra  may,  in  fact,  be  a  strength  of 
that  framework,  rather  than  a  weakness,  reflecting  its  correct¬ 
ness  as  a  model  of  what  computer-based  systems  are  really  capable 
of. 
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APPENDIX  V 

SAMPLE  AXES  SYSTEM  SPECIFICATION 


In  what  follows,  the  axiomatization  of  type  WORD  is  given,  some 
abstract  operations  are  specified,  and  a  description  of  the  primi 
tive  and  abstract  operations  on  the  type  are  given  in  Table  AV-1. 


DEFINE  WORD; 

PRIMITIVE  OPERATIONS ; 


word2  =  Setspaces (word^, natural^) ; 
word2  =  Addelmt (word^, natural^) ; 
word2  =  Lastelmt (word^) ; 
word2  =  Removeelmt (word^) ; 
natural^  =  Nspaces (word^) ; 
natural^  *  Nelmts  (word^)  ; 
boolean^  =  S amew( word word 2) ; 

AXIOMS : 

WHERE  1  IS  A  CONSTANT  NATURAL? 

WHERE  n,n1,n2  ARE  NATURALS; 

WHERE  w,w1,w2  ARE  WORDS; 

WHERE  Null word  IS  A  CONSTANT  WORD; 

N spaces  (Nullword)  *»  Zero; 

Nelmts  (Nullword)  =  Zero; 

Nspaces (Setspaces (w,n) )  =  n; 

Nelmts (Addelmt (w, n) )  -  Sum (Nelmts (w) , 1) ; 

Samew(w,w)  =  True; 

Samew (Setspaces (w,n^) ,  Setspaces (w,n2) )  a  Equal (n^,n2) ; 

Samew( Addelmt (w, n^) ,  Addelmt (w,n2) )  =  Equal(n^,n2) ; 
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TABLE  AV-1 

Description  of  Operations  on  Type  WORD 


OPERATION 

DESCRIPTION 

Nulluord: 

Constant  value,  not  an  operation. 

The  value  of  Wordi  will  be  a  word  with  a  null  string  of 
elements  and  a  space  of  length  zero. 

Setspaces: 

Wordi  x  Nati  Word2 . 

The  element  string  of  Word2  will  be  identical  to  Wordi. 

Nati  will  be  the  size  of  the  space  of  Word2. 

Addelmt : 

Wordi  x  Nati  Word2. 

Add  Element.  Word2  will  be  the  same  as  Wordi  except  the 
element  associated  with  Nati  will  be  concatinated  on  the 
end  of  its  element  string. 

Lastelmt: 

Wordi  Word 2 . 

Last  Element.  The  element  string  of  Word  2  is  the  last 
element  in  the  string  of  Wordi.  If  the  element  string 
of  Wordi  is  null,  the  element  string  of  Word2  will  be 
null  also.  Word2  will  have  a  space  of  size  zero. 

Removeelmt : 

Wordi  -*■  Word2. 

Remove  Element.  Word2  will  be  the  same  as  Wordi  except 
the  last  element  in  the  element  string  will  be  omitted. 

Nspaces : 

Wordi  Nati  • 

Nati  is  the  size  of  the  space  of  Wordi. 

Nclmts: 

Wordi  -*■  Nati  • 

Nati  is  the  number  of  elements  in  the  element  string  of 

Word  i . 

Sanew: 

Wordi  x  Word2  •*  Boolean  i. 

Same  Word?  Booleani  has  the  value  True  if  Wordi  and 
rord2  are  identical  in  element  string  and  space  size. 

It  has  the  value  False  otherwise. 

Lengthw 

Wordi  Nati  ■ 

Length  of  Word.  Nati  is  the  total  length  of  Wordi,  i.e., 
the  sum  of  the  number  of  elements  and  the  size  of  the 
spare  of  Wordi. 

Element: 

Nati  Wordi. 

Creates  a  word  with  a  single  element  corresponding  to  Nati 
and  a  space  of  size  zero. 

Addspaccs: 

Wordi  x  Nati  ■*  Word2. 

Adds  Nati  to  the  size  of  the  space  of  Wordi  to  create 

Word2.  The  element  strings  of  Wordi  and  Word2  are  identical. 

Ndiff: : 

Nati  x  Nat 2  ■*  N'atj. 

Modified  subtraction  defined  on  the  natural  numbers.  If 

Nat2  is  larger  than  Nati,  the  value  of  Nats  is  zero  in¬ 
stead  of  error. 

AV-2 
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3 

•  j 

Lastelmt (Addelmt (w,n) )  =  Element (n) ; 

Removeelmt(Addelmt (w,n) )  *  w; 

Nelmts (Removeelmt (w) )  =  Ndif fz (Nelmts (w) ,1) ; 

Lastelmt (Nullword)  =  REJECT; 

Removeelmt (Nullword)  =  REJECT; 

Samew(w1,w2)  =  And (Equal (Nspaces (w^) Nspaces (w2) ) , 

And (Samew (Lastelmt (w^) ,  Lastelmt (w2) ) , 

(Samew( Removeelmt (w1) ,  Removeelmt (w2) ) ) ) ; 

END  WORE; 

OPERATION:  n  =  Lengthw(w) ; 

WHERE  n  IS  A  NATURAL; 

WHERE  w  IS  A  WORD; 

WHEREBY  n  -  Sum(Nspaces  (w)  , Nelmts  (w) )  ; 

END  Lengthw; 


OPERATION:  w  =  Element (n); 

WHERE  W  IS  A  WORD; 

WHERE  n  IS  A  NATURAL; 

WHEREBY  w  =  Addelmt (REJECT, n) ; 

END  Element; 

OPERATION:  w2  *  Addspaces (w, n) ; 

WHERE  w,w2  ARE  WORDS; 

WHERE  n  IS  A  NATURAL; 

WHEREBY  w2  =  S^tspaces (w, Sum (Nspaces (w) ,n) ) ; 

END  Addspaces; 

OPERATION:  n3  =  Ndif  f  z  (n^n^  ; 

WHERE  n1#n2,n3  ARE  NATURALS; 

EITHER  m,  =  K  f1 (n. ,m,) )  OTHERWISE 
3  zero  i  i 

n3  *  Ndiff (2 (n^ ,n2) ) ; 

PARTITION  OF  (n^nj)  IS 

(a^,n2) | ni<n2 , 

(nl,n2)  Inj^^nj,* 

END  Ndiffz?  AV-3 
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I 

Specification  of  Data  Type:  LINE 

An  algebraic  specification  of  the  line  is  given  and  some  abstract 
operations  that  will  be  used  in  an  example  problem  are  defined. 

Table  AV-2  is  a  description  of  the  primitive  and  abstract  opera¬ 
tions  that  have  been  defined. 

DEFINE  LINE; 

PRIMITIVE  OPERATIONS: 

line^  =  Wline(word^) ; 
word^  »  lstword (line^) ; 
natural i  =  Nwords (line^) ; 
boolean^  =  Samel ( line^ , line2) ; 
line2  *»  Headdine^natural^  ; 
line2  *  Tail (line^, natural^) ; 
line3  «  Conc(linelfline2) ; 

AXIOMS: 

WHERE  2,1  ARE  CONSTANT  NATURALS; 

WHERE  n,nlfn2  ARE  NATURALS; 

WHERE  w,w1,w2  ARE  WORDS; 

WHERE  line,  line^,  line2  ARE  LINES; 

WHERE  Nulline  IS  A  CONSTANT  LINE; 

Samel  (WlinefWj^)  ,Wline(w2) )  «  samew^ ,w2)  ; 

Nwords (Wline(w) )  =  1; 

Samel ( line, line)  *  True; 

Head  (Nulline, n)  *  REJECT; 

Tail  (Nulline, n)  «  REJECT; 

Cone  (Nulline, Nulline)  =  REJECT; 

Cone (Head ( line, n) , Tail (line, n) )  ■  line; 

AV-4 
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OPERATION 


DESCRIPTION 


Wline: 

1st word: 

Nwords : 

Samel: 

Head: 

Tail: 

Cone: 

Nulline 

Length: 

Suraw : 

Compress: 

Compact : 

Pad: 

Padcachw: 


Wordj  -►  Linei. 

Word  to  Line.  A  type  transformation.  Linei  is  a  line  con¬ 
taining  the  single  word  Wordi. 

Linei  -*■  Natj. 

First  Word.  Wordi  is  the  first  word  on  Linei. 

Linei  -*•  Natj. 

Nati  is  the  number  of  words  on  Linei. 

Linei  X  Linei  ■+  Boolean  . 

Same  Line?  Booleani  has  the  value  TRUE  if  Linei  and  Lines 
are  identical.  It  has  the  value  FALJE  otherwise. 

Linei  X  Nati  ■+■  Linez. 

Line2  consists  of  the  first  Nati-1  words  on  Linei.  If  Nati 
is  less  than  or  ;:qual  tc  1,  then  Li.o*^  is  the  NullLine. 

k-inei  X  Nati  -*■  Line?. 

Line2  is  what  remains  of  ..  rafter  the  Tirst  Nati-1  words 
are  removed.  If  Nati  is  greate..  than  NWords (Linei ) ,  ther 
Lines  is  the  NullLine. 

Linei  X  Line2  ■+  Line*. 

Concatination.  Line,  is  the  string  of  words  on  Line2  con- 
catinated  onto  the  end  of  the  string  of  words  on  Linei. 

Constant  value,  not  an  operation. 

Linei  is  the  line  with  a  null  string  of  words. 

Linei  -*•  Nat2. 

Nat 2  is  the  sum  of  the  lengths  of  each  of  the  words  within 
Linei . 

Linei  X  Nati  ■*  Nat 2. 

Sum  of  Word  Lengths.  Nat 2  is  the  sum  of  the  lengths  of  the 
first  Nati  words  on  Linei. 

Linei  **  Line?. 

Line2  is  the  same  as  Linei  except  that  the  site  of  the  space 
preceding  each  word  is  zero  for  the  first  word  and  one  for 
all  others. 

Linei  X  Nati  -*■  Line?, 

Line2  is  the  same  as  Linei  except  that  the  first  Nati  words 
are  compressed. 

Line*  X  Nst2  -*■  line2. 

Line2  is  the  same  as  Linei  except  that  the  size  of  the  space 
of  eacn  word  has  been  increased  by  Nat2. 

Linei  X  Nati  X  Nat2  *'  Line  . 

Pad  Each  Word.  Line2  is  the  same  as  Linei  except  that  the 
size  of  the  space  of  the  first  Nati  words  has  been  increased 
by  Nat 2. 
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Nwords  (Cone  (line^  line ?) )  -  Sum(Nwords  (line^  ,Nwords  (line2) ) ; 
Is tword (Cone (Wline (w) , line) )  *  w; 

EITHER  Head (Wline (w) ,n)  ■  IDENTIFY^ (Wline (w) , 1n)  OTHERWISE 
Head (Wline (w) ,n)  = 

PARTITION  OF  n  IS 
Xn | n=2 , 

2n | n/2 ; 

EITHER  Tail (Wline (w) ,n)  =  IDENTIFY2 (Wline (w) , 1n)  OTHERWISE 

Tail (Wline (w) ,n)  »  KREJECT  (2n) ; 

PARTITION  OF  n  IS 
^n[n<l, 

2  i 

n | n>l ; 

Same)  (Cone  (line^ , line2 )  ,Conc  (line2  ,line^)  )  = 

OR(Samel  (line1 /REJECT)  ,Sa!nel  (line2, REJECT) )  ; 

Head  (Cone  (line^^  /  line2)  ,n) '  = 

KREJECT(ln)  AND  Headdinej^,2^  AND 

Cone  (line1,Head(line2,Ndiffz  (3n,Nwoi:ds  (line^ ) ) )  AND 

IDENTIFY2  (Cone  (line^ine^  ,  4n)  ; 

PARTITION  OF  n  IS 

*n | n<l , 

2 

n| l<n£Nwords (line^) , 

3n | Nwords (line, ) <n£Nwords (Cone (line^, line2) ) ) , 

4 

rJn>Nword<:  (Cone  (line1 ,  linej) ) ; 
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Tail (Cone (line^ ,line2) »n)  = 

K*EJECT(ln) 

Cone  (line^  Tail  (line2rNdiffz(2n,Nwords  (line^ ) ) )  AND 

Cone (Tail (line^, ^n) ,line2)  AND 

IDENTIFY J (Cone (line1,line2) 4n; 

PARTITION  OF  n  IS 

^n|Nwords(Conc(line^,line2)<  n, 

2 

njNwords (line^) <n<Nwords (cone (line^ ,line2) ) , 

^n| l<n£Nwords (line^) , 

4n I n<l; 


END  LINE; 


OPERATION:  n  -  Length  (line^  ; 

WHERE  line1  IS  A  LINE; 

WHERE  n  IS  A  NATURAL; 

WHEREBY  n  =  Sumw(line^ ,Nwords (line^) ) ; 
END  length; 


OPERATION:  n2  »  Sumw(line  n) ; 

WHERE  line1  is  a  LINE; 

WHERE  n,n2  ARE  NATURALS; 

EITHER  n,  -  K„_  ^ (1line1 , Xn)  OTHERWISE 

l  Zero  2^2  22 

WHEREBY  r2  =  Sumw(^line^,  h-1)  +  Lengthw (Extract (  line^,  n)); 

PARTITION  OF  (n,line,)  IS 
1  ^ 

(n,  line, )  |  n  =  Zero, 

2  ^ 

(n,line1)Jn  NOT-  Zero; 

END  Sumw; 


OPERATION:  w  =  Extract( line^,n) ; 

WHERE  w  IS  A  WORD; 

WHERE  linex  IS  A  LINE; 

WHERE  n  IS  A  NATURAL; 

WHEREBY  w  »  lstword(Tail(linelfn) ) ; 

END  Extract; 
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OPERATION:  line2  =  Compress ( line^) ; 

WHERE  line^,line2  ARE  LINES ; 

WHEREBY  line2  =  Compact (line^ ,Nwords ( line^) ) ; 

END  Compress; 

OPERATION:  line2  =  Compact ( line1 , n) ; 

WHERE  n  IS  A  NATURAL; 

WHERE  line1,line2  ARE  LINES; 

WHERE  1  IS  A  CONSTANT  LINE; 

i 

EITHER  WHEREBY  line2  =  Wline (Setspaces (lstword(  line^) ,Zero) ) 
OTHERWISE  WHEREBY  line,  =  Cone (Compact (2line. , 2n-l) , 

Wline^ (Setspaces (Extract (“line^/  n) ,1))) 

PARTITION  OF  (line, ,n)  IS 

(line, ,n) |n<l, 

2  ^ 

(line^,n) ln>l; 

END  Compact; 

OPERATION:  line2  *  Pad ( line^ ,n) ; 

WHERE  line1#line2  ARE  LINES; 

WHERE  n  IS  A  NATURAL; 

WHEREBY  line2  **  Padeachwdine^Nwords (line^)  ,n)  ; 

END  Pad; 

OPERATION:  line2  »  Padeachwlline^^ ^ ,n2) ; 

WHERE  line1,line2  ARE  LINES; 

WHERE  n1#n2  ARE  NATURALS; 

EITHER  WHEREBY  line2  »  (line^n^^)  ) 

OTHERWISE  WHEREBY  line2  «  Cone (Padeach (2line1, 2*1  -  l,2n2), 

2  2' 

Wline  (addspaces (Extract (  line^n^,  n2>)); 
PARTITION  OF  (line^^ ,n1(n;)  IS 

1  (line1#n1#n2)  J n^ **  Zero, 

7 

(line^n^nj)  |  n^  NOT«  Zero; 

END  Padeachw; 
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Line  Justifier 


The  Linejustify  function  is  designed  to  adjust  the  spacing  be¬ 
tween  words  of  a  line  so  that  the  last  element  of  the  last  word 
of  the  line  occurs  at  the  specified  margin.  This  problem, 
suggested  by  (GRI76)  and  modified  in  (HAM76) ,  has  been  re¬ 
formulated  here  to  use  data  type  LINE.  The  function  is  further 
constrained  so  that  the  size  of  the  spaces  between  any  two 
words  on  the  same  line  will  differ  by  no  more  than  one,  and  the 
insertion  of  the  larger  spaces  will  be  staggered  to  the  left  or 
right  i.n  alternating  lines.  Thus,  odd  (even)  lines  will  have 
larger  spaces  separating  words  at  the  left  (right)  of  the  line. 

Also,  the  last  line  of  a  paragraph  will  be  justified  to  the  left 
only,  and  not  to  the  right.  Any  line  which  cannot  be  compressed 
into  the  size  of  the  margin  without  eliminating  a  minimum  word 
spacing  of  size  one  will  return  an  error  condition.  Table  AV-3 
lists  the  names  and  uses  of  variables  of  the  Linejustify  func¬ 
tion,  and  Table  AV-4  lists  the  names  and  uses  of  its  subfunctions. 

FUNCTION:  line2  ■  Linejustify (line^, Margin, Lpty,Ppty) ; 

JOIN  line,  «  Pptychk(Compl, Margin, Lpty,Ppty)  WITH 
2  111 

INCLUDE  Compl  =  Compress (line^)  ALSO 

(Margin, Lpty,Ppty)  ■ 

111 

CLONE ^( Mar gin,Lpty ,Ppty) ; 

EITHER  line,  -  IDENTIFY? (^Compl, Margin, ^Lpty^Ppty)  OTHERWISE 
2  1  111 

JOIN  (2Compl,2Margin,2Lpty)  * 

111 

IDENTIFY?  ,  ,(2Compl,2Margin,2Lpty,2Ppty)  WITH 
1*2,3  111 

2  2  2 

line,  *  Sizechk(  Compl,  Margin,  Lpty) ; 

2  111 
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PARTITION  OF  ( Compl, Mar g in , Lpty ,Ppty)  IS 

111 

* (Compl, Margin, Lpty, Ppty) |Ppty  =  True, 
111 


1 (Compl,Margin,Lpty ,Ppty)  |Ppty  =  False; 

111 

EITHER  line,  *  IDENTIFY? (  2Compl,  2Margin,  2Lpty)  OTHERWISE 
*  1  1  l 

^2  2,  22  _ 

EITHER  line,  *  Calcspaces(  Compl,  Margin,  Lpty)  OTHERWISE 
1  111 


line-  =  K 


2  =  KREJECT(  Cop*1'  ‘Lpty); 


PARTITION  OF  ( 2Compl , 2Margin , 2Lpty)  IS 

111 

1(2Compl,2Margin,2Lpty) | Length (2Compl)  *  2Margin, 
111  1  1 

2  2  2  2  2  2 

(  Compl,  Margin,  Lpty) | Length  (  Compl)  <  Margin, 

111  1  1 

3  2  2  2  2  2 

l  Compl,  Margin,  Lpty)  | Length  (  Compl)  >  Margin; 

1  11  2  1  1 

*2 

JOIN  line-  *  Lptychk (Padedl, Reml,  Lpty)  WITH 
2  2 

22  22 

INCLUDE  (Padedl, Reml)  «  F-{  Compl,  Margin) 

J  1  1 
2  ■L  2 

ALSO  2 Lpty  «  Clone.  (  2Lpty) ; 

2  1  i 

2  *  2 
*2  2 

WHEREBY  Extraspace  -  Ndiffz  l  Margin, Length (  Compl) )» 

2,  1  1 

n.  “  Nwords {  Compl), 

2,1 

Padedl  «  Pad{  Compl, Quot {Extraspace ,p ,)) , 

1 

Reml  «  Rem (Extraspace, n. ) ; 

1  2 
1  2 

EITHER  line-  •  Lef tf ill (  (Padedl, Reml,  Lpty)) 

2  2 

2  22 

OTHERWISE  line-  -  RightfilK  (Padedl, Reml,  Lpty)); 

z  2 
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PARTITION  OF  (Padedl ,Rerol ,  Lpty)  IS 

2 

2  Ir. 

x  (Padedl, Reml,  2Lpty) |  ^Lpty  *  True, 

2  2 

2  2 

2  (Padedl, Reml,  2Lpty) |  2Lpty  =  False? 


JOIN  line2  »  Cone (Taill,Padleftl)  WITH 

JOIN (Taill, Padleftl)  =?  F,  (1Padedl,1Reml) 

1  1  1 

X2 

WITH  ( 1Padedl ,  1Reml)  =  IDENTIFY?  ,( Padedl  ^Penl,  2Lpty)  ; 
1  1  2 
WHEREBY  R  =  (J-Reml,l) , 

1  1 

Laftl  *  Head  (  Padedl, R) , 

!  1 

Taill  -  Tail (Padedl  , P) , 

1 

Padleftl  »  Pad (Leftl, 1) ; 

JOIN  l.ine2  =  Cone (Headl,Padrightl)  WITH 

JOIN (Headl,Padrightl)  *  F,(2Padedl,2Reml) 

*  1  1 

22 

WITH ( 2padedl, 2Reml)  =  IDENTIFY?  ,  ( 2Padedl, 2Reml,  •  2Lpty) ? 
1  1  2 

WHEREBY  Rightl  -  Tail (2Padedi,Ntail) , 

2  1  2 

Ntail  -  Nwords(  Padedl) +1-  Reml, 

1  1 

Padrightl  *  Pad (Rightl, 1) , 

Headl  *  Head (2Padedl, Ntail) ? 

1 

WHERE  line^ line2 ,Compl, Padedl, Leftl, 

Padleftl, Taill, Rightl, Padrightl, Headl  ARE  LINES; 


WHERE  Margin, Extraspace, n^C; 

Ntail, Reml  ARE  NATURALS; 


WHERE  Lpty,Ppty  ARE  BOOLEAN; 
END  Linejustify; 
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TABLE  AV-3 

Key  to  Variable  Names 


NAME 

TYPE 

DESCRIPTION 

Line2 

LINE 

Output  line. 

Linej 

LINE 

Input  line. 

Margin 

NATURAL 

Specified  margin  for  output  line. 

Lpty 

BOOLEAN 

Line  Parity.  True  for  odd  lines.  False  for  even  lines. 

Ppty 

BOOLEAN 

Paragraph  Parity.  True  for  last  line  of  paragraph. 

False  otherwise. 

Compl 

LINE 

Compressed  Line.  Lj  after  it  has  been  left  justified 
and  reduced  with  a  space  of  size  one  between  each  word. 

Lengthcompl 

LINE 

Length  of  CompL. 

Extraspace 

NATURAL 

Size  of  space  needed  to  expand  CompL  to  fill  Margin. 

N 

NATURAL 

Number  of  words  of  CompL. 

Quo 

NATURAL 

Quotient.  Size  of  space  to  be  divided  evenly  among 
the  words  of  CompL. 

Rest 

NATURAL 

Remainder.  Number  of  spaces  that  must  be  increased 
by  one  far  PadedL  to  fill  Margin. 

Padedl 

LINE 

Paded  Line.  The  line  CompL  after  Quo  spaces  have  been 
inserted  evenly  among  all  its  words. 

Leftl 

LINE 

Left  Line.  First  portion  of  PadedL  into  which  Rem 
spaces  will  be  inserted,  one  to  a  word. 

Padleftl 

LINE 

Paded  Left  Line.  The  line  Leftl  after  the  size  of  each 
space  has  been  increased  by  one. 

Taill 

LINE 

Tail  Line.  The  last  portion  of  FadedL  after  LeftL  has 
been  removed  from  it. 

N't  ail 

NATURAL 

Number  of  Words  to  be  removed  from  the  front  of  PadedL 
so  that  increasing  by  one  the  size  of  the  spaces  in 
the  remainder  of  the  line  will  fill  the  margin. 

Right) 

LINE 

Right  Line.  Remaining  portion  of  PadedL  after  the 
first  NTail  words  have  been  removed. 

Padrightl 

LINE 

Paded  Right  L  ne.  RightL  after  each  of  its  spaces 
has  been  inere  sed  by  one. 

Hcadl 

LINE 

head  Line.  First  NTail  words  of  PadedL. 
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Table  AV-4 

Description  of  the  Subfunction  of  LineJustify 


NAME 

DESCRIPTION 

Pptychk 

Paragraph  Parity  Check.  Returns  compressed  line  if  it 
is  the  last  of  the  paragraph. 

Sizechk 

Size  Check.  Examines  the  length  of  the  compressed  line 
to  determine  if  there  is  an  error  or  if  the  line  already 
fills  the  margin. 

Calcspaces 

Calculate  Spaces.  Determines  what  space  can  be  inserted 
evenly  between  words  and  calculates  the  remainder  that 
must  be  inserted  either  to  the  left  or  to  the  right  of 
the  line. 

Iptychk 

Line  Parity  Check.  Determines  which  side  of  the  line  to 
insert  extra  space,  depending  on  line  parity  (LPty) . 

Leftfill 

Inserts  extra  space  to  left  of  line. 

Rightfill 

Inserts  extra  space  to  right  of  line. 
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p 

1= 

fe 


NOTE:  The  purpose  of  this  sample  system  problem  is  to  show  the 
use  of  AXES  from  the  point  of  view  of  explicitly  demonstrating 
the  interfaces  of  the  system  as  they  would  appear  to  an  automatic 
analyzer.  We  are  not  attempting  here  to  show  various  shorthand 
methods  that  are  available  to  the  user.  Thus,  this  sample  prob¬ 
lem  does  not  include,  for  example,  the  definition  and  the  use  of 
new  abstract  control  structures  which  would  both  shorten  the 
description  of  the  system  and  provide  for  more  reliable  communi¬ 
cation  from  the  standpoint  of  the  human  analyzer.  An  example 
of  such  a  mechanism  is  demonstrated  by  the  Fail  Structure  (c.f. 
AXES  Syntax  Description,  Section  14.0). 
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NOMENCLATURE 


In  the  description  of  AXES  the  following  nomenclature  will  be 
used. 

means  "is". 

"{  }"  means  choose  one  of  the  rows  contained  within. 

"[  ]"  means  the  enclosed  is  optional. 

" means  repeat  with  different  values  as  often  as 
necessary. 

In  the  syntax  of  AXES,  the  following  nomenclature  will  be  used. 


Upper  case  names  will  designate  lexical  items  of  AXES  (key¬ 
words)  . 


"set  of  variables"  means  a  list  of  variables  possibly  en¬ 
closed  in  parentheses. 


Constants  and  abstract  control  structure  names  begin  with 
an  upper  case  character  followed  by  zero  or  more  lower  case 
characters . 


A  variable  is  indicated  by  all  lower  case  characters. 


A  value  of  a  particular  data  type  can  be  indicated  by  the 
name  of  the  data  type  in  lower  case  characters,  possibly 
subscripted. 
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STRUCTURE  l.  . 

"STRUCTURE:"  y  S  "("  x  ");" 
declaration. . . 
definition. . . 

"SYNTAX:"  user  defined  syntax";" 

"END"  S 

user  defined  syntax:  =  connector^  y^  "="  S^  " ( "x^") " . . . 

connector  y„  "="  Sn  *("x  ")" 
n  Jn  n  n 

where  x,  y  are  variables  or  sets  of  variables  whose  values  are 
in  the  same  types  as  the  members  of  the  ordered  pairs  that  make 
up  the  mappings  in  the  tuples  of  S; 
and  S  is  a  structure  name; 

and  connector ^  is  a  user-defined  name,  possibly  empty; 

and  y  =  S^(x^)  is  an  unspecified  mapping  (see  Section  10.0  for 

use  of  user-defined  syntax) . 

The  unspecified  mapping  names,  used  in  definition  statements  within 
a  structure,  are  nested  subscripted  names  with  respect  to  the  root 
module  name. 


OPERATION 

"OPERATION:"  y  "  =  "  L  "("  x 
declaration. . . 
definition. . . 

"END"  L 

where  x,  y  are  variables  or  sets  of  variables  whose  values  are 

in  the  same  types  as  the  members  of  the  ordered  pairs  which  are 
the  mappings, 

and  L  is  an  operation  name. 
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FUNCTION 


l. 


"FUNCTION:"  y  "  =  "  F  "  ("  x 
declaration. . . 
definition. . . 

"END"  F 

where  x,  y  are  particular  variables  or  particular  sets  of  vari 
ables  whose  values  are  in  the  same  types  as  the  members  of  the 
ordered  pairs  which  are  the  mappings, 
and  F  is  a  function  name. 


DECLARATION 

In  declaration^ ,  x  is  a  variable,  y^,...  is  a  set  of  variables, 

T  is  a  constant  or  variable  data  type  name,  and  ”S"  concatenated 
with  T  denotes  a  plural  type  name. 


declaration^ :  =  "WHERE"!  x  "IS" 


Xi 


x  "IS* 


'AN' 

•A 

•AN 


„  |"  CONSTANT"]  T 


"I  It! -or-.  .  .tJ 


"OF  SOME  TYPE* 


’ARE" 


("CONSTANT"]  T"S" 
,  T i . . .T"S" 


•S"  "OR". . .T  “S 
n 


A1 

'OF  SOME  TYPES" 
"OF  THE  SAME  TYPE’ 


'SOME  TYPE' 
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In  declarat  j.or^ ,  x  is  a  variable  or  a  set  of  variables  enclosed 
in  parentheses,  -^y  j.s  variable  or  set  of  variables  whose  values 
are  members  of  the  members  of  a  partition  of  the  set  of  values 
of  the  variables  that  x  represents. 


declaration^:  =  'TART1T 


1T10N  OH"  x  "IS"  ANY  PARTlTI™ 

•y  "  |"  tv j  .  .  \v  "|"  tv. 


true  val  exp: 


!•'  "("expj")" 

F  "("exp. . .")" 
exp  F  exp 


tv.  :  = 

1 


true  val  'exp 

"("true  val  cxp1  "."...true  val  exp.")' 


true  val  exp^  evaluates  to  the  boolean  value  True,  and  exp  is 
in  terms  of  x  and  values  of  x. 


DEFINITION 

In  a  definition,  y,x  are  variables  or  sets  of  variables,  and 
F  is  a  structure,  operation,  or  function. 


definition^:  = 


y  p  m  ^  x  K|  « 

[primitive  definition 
I  user-defined  definition 
mapping  assertion 


Primitive  definition: 


definition^  "AND"... 
def inition^" ; " 
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user-defined  definition 


connector^ .definition^. . . 

connector  definition 
n  n 

where  a  set  of  connectors  is  defined  in  a  particular  structure 
definition  (see  Section  8.0). 


mapping  assertion:  =  "WHEREBY"  y  exp'1;" 

EXPRESSIONS 


value 
x 

F (exp) 
exp  F  exp 
(exp) 
exp, . . . 

where  F  is  an  operation  or  a  function  name  and 
x  is  a  variable. 

CORRESPONDENCE  BETWEEN  INTRINSIC  DATA  TYPE  OPERATIONS  AND  INFIX  SYMBOLS 


Operation 

Or,  por 
And ,  Pand 

Not,  Pnot,  Iopp,  Ropp 

Same,  Ident,  Equal,  ?Equal?, 
Plequal? ,  ?Requal? 

?>?,  ?I>?,  ?R>? 

Sum,  Isum,  Rsum 

Idiff,  Rdiff 

Prod,  Iprod,  Rprod 
Rdiv 

Cone 
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The  precedence  of  AXE.r>  operators  is  as  follows: 


Highest 

**  prefix  +  - 

*  / 

+  - 

=<><=>= 

& 

Lowest 

Operator  Associativity 

If  an  expression  contains  multiple  jperators  of  equal  precedence, 
the  meaning  of  the  expression  is  determined  by  -he  associativity 
of  the  operators.  All  prefix  operators  and  the"**"  infix  operator 
are  right-associative,  and  all  other  operators  are  lef t-associa- 
tive. 

Left-associative  operators  give  priority  to  other  operators  of 
equal  precedence  to  their  left,  while  right-associative  operators 
give  priority  to  operators  of  equal  precedence  to  their  right. 

For  example, 

DATA  TYPES 

"DATA  TYPE:"  name 
"PRIMITIVE  OPERATIONS;" 

primitive  operations... 

"AXIOMS;" 

declaration. . . 

assertion  (about  a  type) . . . 

"END"  name";" 


where 

(1)  name  is  the  abstract  data  type  name. 


AVI- 6 

HIGHER  ORDER  SOFTWARE,  INC  •  843  MASSACHUSETTS  AVENUE  •  CAMBRIDGE,  MASSACHUSETTS  02139  •  (617)  661-8900 


primitive  operation :=  typenamei  P.  "{"  typename ; 

•  J 

where  typename^  is  a  data  type  name  in  lower-case  characters 
and  k  is  an  integer,  possibly  empty,  and  P.  is  a  primitive 
operation  name. 


assertion  {about  a  type) :  = 


definition^ 
F’V'exp^ " )  " 


definition. 


intrinsic  types:  « 


I  boolean 
natural 

integer  j 

rational 
property  (of  T) 
set  (of  T) 
line 


value: 


I  boolean  value 
natural  value 
integer  value 
rational  value 
property  (of  7) value, 
set  (of  T)  value 
line  value 

i  extrinsic  value  , 


boolean  value: 


True 

False 


natural  value: 


integer  value: 


{  }  natural 
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rational  value: 


property  (of  T) 
value: 


set  (of  T)  value: 


line  value: 


{integer^, 
integer^ . integer2 


("E"  integer] 


"PROPERTY  OF"  t  "IN"  T" | "true 
val  exp^ 

1{value^ i . . . ) 

"SET  OF"  t  "IN"  T  "|"  true  val  expx 

’any  finite  string  of  symbols 
possibly  empty' 


Extrinsic  data  type  values  are  defined  as  "'CONSTANT'  T"  using 
a  declaration^  statement  (Section  9.0). 


"DERIVED  OPERATION:"  y  D  "("  x  ");" 

declaration. . . 
assertion(about  D) . . . 

"END"  D  ";" 

where  x,y  are  variables  or  sets  of  variables  and  D  is  a 
derived  operation  name. 

(definition^  definition^ 

assertion(about  D)  :  *  [r^  ("exp^T  F2"("exp2")" 


AVI-C 

HICHEk  ORDER  SOFTWARE,  INC  -  843  MASSACHUSETTS  AVENUE  .  CAMBRIDGE,  MASSACHUSETTS  021 3<>  .  (617)  661*8900 


